Changes

* Jobs without database access will never be locked. Globally locking jobs can now be executed in parallel with non-locking jobs.* 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{{Option|PARALLEL]] }} option. ==External Side Effects== Access to external resources (files on hard disk* By default, HTTP requestsread transactions are favored, ...) is not controlled by the transaction monitor of BaseX unless specified by the user. ===XQuery Locking Options=== Custom locks and transactions that access no databases can be acquired by setting evaluated even if the BaseX-specific XQuery options {{Code|query:read-lock}} and {{Code|query:write-lock}}transactions limit has been reached. Multiple option declarations may occur in the prolog of a query, but multiple values This behavior can also be separated with commas in a single declaration. These locks are in another namespace than changed via the database names: the lock value {{CodeOption|factbookFAIRLOCK}} will not lock a database named factbook. These option declarations will put read locks on ''foo'', ''bar'' and ''batz'' and a write lock on ''quix'': <pre class="brush:xquery">declare option query:read-lock "foo,bar";declare option query:read-lock "batz";declare option query:write-lock "quix";</pre> ===Java Modules=== Locks can also be acquired on [[Java Bindings#Locking|Java functions]] which are imported and invoked from an XQuery expression. It is advisable to explicitly lock Java code whenever it performs sensitive read and write operations.

* {{Code|delete nodes docdb:open('test')//*[string-length(local-name(.)) > 5]}}, write-locking of "test"

All databases A global lock will be locked by queries assigned if the name of the following kinddatabase is not a static string:

* {{Code|for $db in ('db1', 'db2') return docdb:open($db)}}

* <code>let $db := 'test' return insert nodes <test/> into db:open($db)</code> The functions [[Databases#XML Documents|fn:doc]] and [[Databases#XML Documents|fn:collection]] can also be used to address that are not stored in a database. However, this may lead to unwanted locks, and you have two options to reduce the number of locks: No database lookups will take place if {{Option|WITHDB}} option is disabled, or if {{Function|Fetch|fetch:xml}} is used instead of [[Databases#XML Documents|fn:doc]]. You can consult the query info output (which you find in the [[GUI#Visualizations|Info View]] of the GUI or which you can turn on by setting {{Option|QUERYINFO}} to {{Code|true}}) to find out which databases have been locked by a query. =XQuery Locks= {{Mark|Updated with Version 9.4:}} Single lock option for reads and writes. By default, access to external resources (files on hard disk, HTTP requests, ...) is not controlled by the transaction monitor of BaseX. Custom locks can be assigned via annotations, pragmas or options: * A lock string may consist of a single key or multiple keys separated with commas.* Internal locks and XQuery locks can co-exist. No conflicts arise, even if a lock string equals the name of a database that is locked by the transaction manager.* The lock is transformed into a write lock by making the corresponding expression updating. ==Annotations== In the following module, lock annotations are used to prevent concurrent write operations on the same file: <syntaxhighlight lang="xquery">module namespace config = 'config'; declare %basex:lock('CONFIG') function config:read() as xs:string { file:read-text('config.txt')}; declare %updating %basex:lock('CONFIG') function config:write($data as xs:string) { file:write-text('config.txt', $dbdata)};</syntaxhighlight> Some explanations: * If a query calls the <code>config:read</code> function, a read lock will be acquired for the user-defined {{Code|CONFIG}} lock string before query evaluation.* If <code>config:write</code> is called by a query, a write lock will be applied.* If another query calls <code>config:write</code>, it will be queued until the first query is evaluated. ==Pragmas== Locks can also be declared via pragmas:

You can consult the query info <syntaxhighlight lang="xquery">update:output (which you find in the [[GUI(# basex:lock CONFIG #Visualizations|Info View]] of the GUI or which you can turn on by setting ) { file:write('config.xml', <codeconfig/>[[Options#QUERYINFO|QUERYINFO]])})</codesyntaxhighlight> to  The write locks is enforced via the {{Code|trueUpdate|update:output}}. ==Options== Locks for the functions of a module can also be assigned via option declarations: <syntaxhighlight lang="xquery">declare option basex:lock 'CONFIG'; update:output(file:write('config.xml', <config/>)) </syntaxhighlight> Once again, a write lock is enforced. ==Java Modules== Locks can also be acquired on [[Java Bindings#Locking|Java functions]] which are imported and invoked from an XQuery expression. It is advisable to find out which databases have been locked by a queryexplicitly lock Java code whenever it performs sensitive read and write operations.