Changes

Jump to navigation Jump to search
599 bytes added ,  17:33, 28 July 2020
* Subsequent operations (read or write) will be queued until the updating transaction has completed.
* 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 {{Option|PARALLEL}} option.* By default, read transactions will now be are favored, and transactions that access no databases can be evaluated even if the transactions limit has been reached. This behavior can be changed via the {{Option|FAIRLOCK}} option.
Each ==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=== 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 has its own queueopened 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: An update on database open('test')//*[string-length(local-name(.)) > 5]}}, write-locking of "test" A global lock will not block operations on be assigned if the name of the database B. This is under the premise that it 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 statically determinedused to address that are not stored in a database. However, i.e.this may lead to unwanted locks, before and you have two options to reduce the transaction number of locks: No database lookups will take place if {{Option|WITHDB}} option is evaluateddisabled, which databases will be accessed by a transaction (see or if {{Function|Fetch|fetch:xml}} is used instead of [[Databases#LimitationsXML Documents|belowfn:doc]]). The number of maximum parallel transactions  You can be adjusted with consult the query info output (which you find in the [[OptionsGUI#PARALLELVisualizations|PARALLELInfo View]] optionof 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==
By default, access to external resources (files on hard disk, HTTP requests, {{Mark|Updated with Version 9.4:}} Single lock option for reads and writes..) is not controlled by the transaction monitor of BaseX. You can use custom XQuery locks to do so:
===Query Options===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:
* You can declare custom locks via the {{Code|query:read-A lock}} and {{Code|query:write-lock}} options in the query prolog.* The value string may consist of the option contains the lock string, a single key or multiple ones (keys separated with commas).* 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.
In the following two example modules, locks have been added to prevent concurrent write operations on the same file:==Annotations==
<pre class="brushIn the following module, lock annotations are used to prevent concurrent write operations on the same file:xquery">module namespace read = 'read';
(:~ Read lock on CONFIG key. :)<syntaxhighlight lang="xquery">declare option query:read-lock module namespace config = 'CONFIGconfig';
declare %basex:lock('CONFIG') function config:read:config() as xs:string {
file:read-text('config.txt')
};
</pre>
<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) {
file:write-text('config.txt', $data)
};
</presyntaxhighlight>
Some explanations:
* 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 waitIn practice, it’s often sufficient to only work with (exclusive) write locks. ===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.==Pragmas==
==Limitations==Locks can also be declared via pragmas:
<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}}.
* {{Code|DROP DB new*}}: drop all databases starting with "new"==Options==
===XQuery===Locks for the functions of a module can also be assigned via option declarations:
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"
All databases will be locked by queries of the following kind:Once again, a write lock is enforced.
* {{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.
=File-System Locks=
=Changelog=
 
;Version 9.4
* Updated: Single lock option for reads and writes.
 
;Version 9.1
* Updated: Query lock options were moved from {{Code|query}} to {{Code|basex}} namespace.
;Version 8.6
Bureaucrats, editor, reviewer, Administrators
13,550

edits

Navigation menu