Bureaucrats, editor, reviewer, Administrators
13,550
edits
Changes
Jump to navigation
Jump to search
Note:An unexpected abort of the server during a transaction, caused by a hardwarefailure or power cut, may lead to an inconsistent database state if a transaction was active at the shutdown timePlease note that locks are not synchronized between BaseX instances that run in different JVMs. So we advise to usethe [[Commands#CREATE BACKUP|BACKUP]] command If concurrent write operations are to backup your database regularly. If the worst case occursbe performed, you can try we generally recommend working with the [[Commands#INSPECT|INSPECT]] command to check if your database has obvious inconsistencies, and [[Commands#RESTORE|RESTORE]] to restore a previous version of client/server or the databaseHTTP architecture .
The transaction monitor ensures that just one writing transaction or an arbitrary amount In the following example, all databases will be blocked, because the name of reading transactions ''per the second database'' are active at , which will be opened in the same time.query, will only be known after having opened the first database:
Deadlocks are prevented by using preclaiming two phase locking. Execution is starvation<pre class="brush:xquery">let $db1 := db:open('catalog')//db-free as lock acquisition is queued per database. Due to the specifics of XQuery Update, all updates are written at the end of the query. Locking is strict with the exception that databases for which BaseX recognizes it will not write to are downgraded to read locks.name[@id = '123']let $db2 := db:open($db)return delete node $db2//text()</pre>
Locks are not synchronized between multiple BaseX instances. We generally recommend working The number of maximum parallel transactions can be adjusted with the client/server architecture if concurrent write operations are to be performed[[Options#PARALLEL|PARALLEL]] option.
no edit summary
This article is part of the [[Advanced User's Guide]].
The BaseX client-server architecture offers ACID -safe transactions,
with multiple readers and writers. Here is some more
information about the transaction management.
=TransactionIntroduction=
In a nutshell, a transaction is equal to a command or query. So each command or query sent to the server becomes a transaction.
Incoming requests are parsed and checked for errors on the server. If the command or query is not correct, the request will not be executed,and the user will receive an error message. Otherwise the request becomes a transaction and gets into the transaction monitor.
Note also that an unexpected abort of the server during a transaction, caused by a hardware failure or power cut, may lead to an inconsistent database state if a transaction was active at shutdown time. So it is advisable to use the [[Commands#CREATE BACKUP|BACKUP]] command to regularly backup your database. If the worst case occurs, you can try the [[Commands#INSPECT|INSPECT]] command to check if your database has obvious inconsistencies, and use [[Commands#RESTORE|RESTORE]] to restore the last backed up version of the database. ==XQuery Update Transactions==
Many update operations are triggered by [[Update|XQuery Update]] expressions. When executing an updating query, all update operations of the query are stored in a pending update list. They will be executed all at once, so the database is updated atomically. If any of the update sub-operations is erroneous, the overall transaction will be aborted.
=Concurrency Control=
BaseX provides support for multiple read and single write operations (using preclaiming and starvation-free two phase locking ). This means that read transactions are executed in parallel. If an updating transaction comes in, it will be queued and executed after all previous read transaction have been executed. Subsequent operations will also be queued until the updating transaction has completed. Each database has its own queue: An update on database level. Writing transactions do A will not necessarily block all other transactions any moreoperations on database B. The number of parallel transactions This is under the premise that it can be limited statically determined (i.e., before the transaction is evaluated) which databases will be accessed by setting the [[Options#PARALLEL|PARALLEL]] option.a transaction:
<pre class==Transaction Monitor=="brush:java">OPEN db; ADD factbook.xml; CLOSEXQUERY insert node <a/> into db:open('db')/*</pre>
==External Side Effects==
Access to external resources (files on hard disk, HTTP requests, ...) is not controlled by BaseX' the transaction monitor of BaseX unless specified by the user.
===XQuery Locking Options===
