Changes

* Locks *''cannot be synchronized* between '' across BaseX instances that run in different JVMs. If concurrent write operations are to be performed, we generally recommend working with the client/server or the HTTP architecture .* 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.

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 A will not block operations on database B* Read transactions are executed in parallel. This is under the premise that * If an updating transaction comes in, it can will be statically determined queued and executed after all previous read transaction have been executed.* Subsequent operations (i.e., before the transaction is evaluatedread or write) which databases will be accessed by a queued until the updating transaction:has completed.

<pre class="brushEach database has its own queue:java">OPEN db; ADD factbookAn update on database A will not block operations on database B.xml; CLOSEXQUERY insert node <This is under the premise that it can be statically determined, i.e., before the transaction is evaluated, which databases will be accessed by a/> into db:opentransaction ('db'see [[#Limitations|below]])/*</pre>. The number of maximum parallel transactions can be adjusted with the [[Options#PARALLEL|PARALLEL]] option.

In the following exampleWith {{Version|8.6}}, all databases will be blocked, because the name of the second database, which will be opened in the query, will only be known after having opened the first databaselocking has been improved:

<pre class="brush:xquery">let $db1 := db:open('catalog')//db* Jobs without database access will never be locked. Globally locking jobs can now be executed in parallel with non-name[@id = '123']locking jobs.let $db2 * A {{Option|FAIRLOCK}} option has been added:= db:open($db)return delete node $db2//text()</pre> The number of maximum parallel By default, read transactions will now be favored, and transactions that access no databases can be adjusted with evaluated even if the [[Options#PARALLEL|PARALLEL]] optiontransactions limit has been reached.

As XQuery is a very powerful language, deciding Deciding which databases will be accessed by a query complex XQuery expression is a non-trivialtask. Optimization is work in progress.The current identification Database detection works for the following types of which databases to lock is limited to queries that access the currently opened database, XQuery functions that explicitly specify a database, and expressions that address no database at all. Some examples on database-locking enabled queries, all of these can be executed in parallel:

Some examples on All databases will be locked by queries that are not supported by database-locking yetof the following kind:

* <code>let $db := 'factbook' return doc($db)</code>, will read-lock: referencing database names isn’t supported yet* {{Code|for $db in ('factbookdb1', 'db2') return doc($db)}}, will read-lock globally* {{Code|doc(doc('test')/reference/text())}}, will read-lock globally* <code>let $db := 'test' return insert nodes <test/> into doc($db)</code>, will write-lock globally

A list of all locked databases is You can consult the query info output if <code>[[Options#QUERYINFO|QUERYINFO]]</code> is set to {{Code|true}}. <!-- and (which you find in the GUI's [[GUI#Visualizations|Info View]] --> If you think that too much is locked, please give us a note on our [http://basex.org/open-source/ mailing list] with some example code. ===GUI=== Database locking is currently disabled if of the BaseX GUI is used. ==Process Locking== In order to enable locking or which you can turn on global (process) level, the option by setting <code>[[Options#GLOBALLOCKQUERYINFO|GLOBALLOCKQUERYINFO]]</code> can be set to {{Code|true}}. This can e.g. be done ) to find out which databases have been locked by editing your {{Code|.basex}} file (see [[Options]] for more details). If process locking is active, a process that performs write operations will queue all other operationsquery.

During the term of a database update, a locking file {{Code|upd.basex}} will reside in that database directory. If the update fails for some unexpected reason, or if the process is killed ungracefully, this file may will not be deleted. In this case, the database cannot be opened anymore using the default commands, and the message "Database ... is being updated, or update was not completed" will be shown instead.  If the locking file is manually removed, you may be able to reopen the database, but you should be aware that database may have got corrupt due to the interrupted update process, and you should revert to the most recent database backup.

To avoid database corruptions that are caused by accidental write operations running in from different JVMs, a shared lock is requested on the database table file ({{Code|tbl.basex}}) whenever a database is opened. If an update operation is triggered, and if no exclusive lock can be acquired, it will be rejected with the message "Database ... is currently opened by another process." if no exclusive lock can be acquired.

As the standalone versions of BaseX (command-linePlease note that you cannot 100% rely on this mechanism, GUI) cannot as it is not possible to synchronize operations across different JVMs. You will be synchronized with other BaseX instances, we generally recommend working with safe when using the client/server or HTTP architecture if concurrent write operations are to be performed.