Changes

==XQuery LocksLimitations==

* You can declare custom locks via the {{Code|query:read-lockDROP DB new*}} and {{Code|query:write-lock}} options in the query prolog.* The value of the option contains the lock string, or multiple ones (separated drop all databases starting 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 be locked by the transaction manager)."new"

<pre class="brushDeciding which databases will be accessed by a complex XQuery expression is a non-trivial task. Database detection works for the following types of queries:xquery">module namespace read = 'read';

* {{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:~ Read lock on CONFIG key. :sum(1 to 100)}}, locking nothing at alldeclare option query* {{Code|delete nodes db:read-lock open('CONFIGtest';)//*[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]]. 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:config() as xs:string {

<pre class="brush:xquery">module namespace write = 'write'; (:~ Write lock on CONFIG key. :)declare option query%updating %basex:write-lock ('CONFIG'; declare ) function config:write:file($dataas xs:string) {

</presyntaxhighlight>

* If a query is parsed that is going to call calls the <code>config:read:file</code> function, a read lock will be acquired for the user-defined {{Code|CONFIG}} lock string before query evaluation.* If <code>config:write:file</code> is referenced called by a query, a write lock on this lock string will be set for this queryapplied.* If a another query references calls <code>config:write:file</code>, it will be queued until there is no running query left that has {{Code|files}} locked.* If the writing first query will be is evaluated, all other queries that will set a {{Code|files}} lock (reading or writing) will have to wait. In practice, it’s often sufficient to only work with (exclusive) write locks. ===Java Modules===

<syntaxhighlight lang===Commands==="xquery">update:output((# basex:lock CONFIG #) { file:write('config.xml', <config/>)})</syntaxhighlight>

Database locking works with all commands unless the glob syntax The write locks is used, such as in enforced via the following command call{{Code|Update|update:output}}.

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<syntaxhighlight lang="xquery">declare option basex:lock 'CONFIG';

* {{Code|//item}}, read-locking of the database opened by a client* {{Code|docupdate:output(file:write('factbookconfig.xml')}}, read-locking of "factbook"* {{Code|collection('db<config/path/to/docs'>)}}, read-locking of "db"* {{Code|fn:sum(1 to 100)}}, locking nothing at all* {{Code|delete nodes doc('test')<//*[string-length(local-name(.)) syntaxhighlight> 5]}}, write-locking of "test"

* {{Code|for $db in ('db1', 'db2') return doc($db)}}* {{Code|doc(doc('test')/reference/text())}}* <code>let $db := 'test' return insert nodes <test/> into doc($db)</code>=Java Modules==

You Locks can consult the query info output (which you find in the also be acquired on [[GUIJava Bindings#VisualizationsLocking|Info ViewJava functions]] of the GUI or which you can turn on by setting <code>[[Options#QUERYINFO|QUERYINFO]]</are imported and invoked from an XQuery expression. It is advisable to explicitly lock Java code> to {{Code|true}}) to find out which databases have been locked by a querywhenever it performs sensitive read and write operations.