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 .

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 be statically determined, i.e., before the transaction is evaluated) which databases will be accessed by a queued and executed after all previous read transaction have been executed.* Subsequent operations (see [[#Limitations|below]]read or write). The number of maximum parallel transactions can will be adjusted with queued until the [[Options#PARALLEL|PARALLEL]] optionupdating transaction has completed.

Access to external resources (files on hard diskWith {{Version|8.6}}, HTTP requests, ...) is not controlled by the transaction monitor of BaseX unless specified by the user.locking has been improved:

Custom locks can be acquired by setting the 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 can also be separated with commas in a single declaration. These locks are in another namespace than the database names: the lock value {{Code|factbook}} will not lock a database named factbook.Locks==

These By default, access to external resources (files on hard disk, HTTP requests, ...) is not controlled by the transaction monitor of BaseX. You can use custom XQuery locks to do so: ===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 will put 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 on ''foo''allow parallel access.* The internal locks and XQuery locks can co-exist (there will be no conflicts, ''bar'' and ''batz'' and even if your lock string equals the name of a database that will be locked by the transaction manager). In the following two example modules, locks have been added to prevent concurrent write lock operations on ''quix''the same file:

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

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.