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 .

Each database has its own queue: An update on database A will not block operations on database B. 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 transaction (see [[#Limitations|below]]). The number of maximum parallel transactions can be adjusted with the [[Options#PARALLEL|PARALLEL]] option.

Access to external resources (files on hard disk* Jobs without database access will never be locked. Globally locking jobs can now be executed in parallel with non-locking jobs.* A {{Option|FAIRLOCK}} option has been added: By default, HTTP requestsread transactions will now be favored, ...) is not controlled by the transaction monitor of BaseX unless specified by and transactions that access no databases can be evaluated even if the usertransactions limit has been reached.

===XQuery Locking Options=Locks==

Custom locks can be acquired By default, access to external resources (files on hard disk, HTTP requests, ...) is not controlled by setting the transaction monitor of BaseX-specific XQuery options {{Code|query:read-lock}} and {{Code|query:write-lock}}. Multiple option declarations may occur in the prolog of a query, but multiple values You can also be separated with commas in a single declaration. These use custom XQuery locks are in another namespace than the database namesto do so: the lock value {{Code|factbook}} will not lock a database named factbook.

These ===Query Options=== * You can declare custom locks via the {{Code|query:read-lock}} and {{Code|query:write-lock}} options in the query prolog.* The value of the option declarations contains the lock string, or multiple ones (separated with commas).* Similar to the internal database locks, write locks block all other operations while read locks allow parallel access.* The internal locks and XQuery locks can co-exist (there will be no conflicts, even if your lock string equals the name of a database that will put read be locked by the transaction manager). In the following two example modules, locks have been added to prevent concurrent write operations on the same file: <pre class="brush:xquery">module namespace read = 'read'foo'', ''bar'' and ''batz'' and a write ; (:~ Read lock on CONFIG key. :)declare option query:read-lock 'CONFIG'quix; declare function read:config() { file:read-text('config.txt':)};</pre>

declare option querymodule namespace write = 'write'; (:read-~ Write lock "foo,bar";on CONFIG key. :)declare option query:readwrite-lock "batz"'CONFIG'; declare option queryfunction write:file($data) { file:write-lock "quix"text('config.txt', $data)};

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 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.".