Changes

==Limitations== ===Commands=== Database locking works with all commands unless the glob syntax is used, such as in the following command call: * {{Code|DROP DB new*}}: drop all databases starting with "new" ===XQuery Locks=== Deciding which databases will be accessed by a complex XQuery expression is a non-trivial task. Database detection works for the following types of queries: * {{Code|//item}}, read-locking of the database opened by a client* {{Code|doc('factbook')}}, read-locking of "factbook"* {{Code|collection('db/path/to/docs')}}, read-locking of "db"* {{Code|fn:sum(1 to 100)}}, locking nothing at all* {{Code|delete nodes db:open('test')//*[string-length(local-name(.)) > 5]}}, write-locking of "test" A global lock will be assigned if the name of the database is not a static string: * {{Code|for $db in ('db1', 'db2') return db:open($db)}}* {{Code|doc(doc('test')/reference/text())}}* <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]].

By default, access to external resources You can consult the query info output (files which you find in the [[GUI#Visualizations|Info View]] of the GUI or which you can turn on hard disk, HTTP requests, ...by setting {{Option|QUERYINFO}} to {{Code|true}}) is not controlled to find out which databases have been locked by the transaction monitor of BaseXa query. You can use custom XQuery locks to do so:

===Options, Pragmas, Annotations==XQuery Locks=

* You can declare custom read {{Mark|Updated with Version 9.4:}} Single lock option for reads and write 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 optionsannotations, pragmas or function annotations.options: * The value of the A lock string may contain one consist of a single key or multiple lock keys (separated with commas). The default value is an empty string.* Similar to the internal database locks, write locks block all other operations while read locks allow parallel access.* The internal Internal locks and XQuery locks can co-exist (there will be no . No conflictsarise, even if your a lock string equals the name of a database that will be is locked by the transaction manager).* The lock is transformed into a write lock by making the corresponding expression updating. ==Annotations==

<pre classsyntaxhighlight lang="brush:xquery">

declare %basex:read-lock('CONFIG') function config:read() as xs:string {

declare %updating %basex:write-lock('CONFIG') function config:write($dataas xs:string) {

</presyntaxhighlight>

* If <code>config:write</code> is called by a query, a write lock on this lock string will be set for this queryapplied.* If a another query calls <code>config:write</code>, it will be queued until there is no running query left that has {{Code|CONFIG}} locked.* If the writing first query will be is evaluated, all other queries that will set a {{Code|CONFIG}} lock (reading or writing) will have to wait.

Locks can also be declared via pragmas: <pre classsyntaxhighlight lang="brush:xquery">update:output((# basex:write-lock CONFIG #) {

})</presyntaxhighlight>

Locks for The write locks is enforced via the functions of a module can be assigned via option declarations{{Code|Update|update:output}}.

<pre class="brush:xquery">declare option basex:write-lock 'CONFIG';file:write('config.xml', <config/>)</pre>=Options==

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 <syntaxhighlight lang="xquery">declare option basex:lock Java code whenever it performs sensitive read and write operations.'CONFIG';

* {{Code|DROP DB new*}}: drop all databases starting with "new" ===XQuery=== Deciding which databases will Locks can also be accessed by a complex XQuery expression is a non-trivial task. Database detection works for the following types of queries: * {{Code|//item}}, read-locking of the database opened by a client* {{Code|doc('factbook')}}, read-locking of "factbook"* {{Code|collection('db/path/to/docs')}}, read-locking of "db"* {{Code|fn:sum(1 to 100)}}, locking nothing at all* {{Code|delete nodes db:open('test')//*acquired on [string-length(local-name(.)) > 5]}}, write-locking of "test" A global lock will be assigned if the name of the database is not a static string: * {{Code|for $db in ('db1', 'db2') return db:open($db)}}* {{Code|doc(doc('test')/reference/text())}}* <code>let $db := 'test' return insert nodes <test/> into db:open($db)</code> The functions [[DatabasesJava Bindings#XML DocumentsLocking|fn:docJava functions]] which are imported and [[Databases#XML Documents|fn:collection]] can also be used to address that are not stored in a databaseinvoked from an XQuery expression. You have two options to reduce the number of locks that are triggered by these functions. No database lookups will take place if {{Function|Fetch|fetch:xml}} It is used, or if {{Option|WITHDB}} option is disabled. 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}} advisable to {{Code|true}}) to find out which databases have been locked by a queryexplicitly lock Java code whenever it performs sensitive read and write operations.