Bureaucrats, editor, reviewer, Administrators
13,550
edits
Changes
Jump to navigation
Jump to search
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|PARALLEL]] option.==XQuery Locks==
With {{Version|8By default, access to external resources (files on hard disk, HTTP requests, .6}}, locking has been improved..) is not controlled by the transaction monitor of BaseX. You can use custom XQuery locks to do so:
* A {{Option|FAIRLOCK}} option has been added: By default, read transactions will now be favored, and transactions that access no databases can be evaluated even if the maximum limit has been reached.* A globally locking job can now be executed in parallel with a non-locking job.===Query Options===
==External Side Effects==* 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 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 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).
Access In the following two example modules, locks have been added to external resources (files prevent concurrent write operations on hard disk, HTTP requests, ...) is not controlled by the transaction monitor of BaseX unless specified by the user.same file:
Custom locks can be acquired by setting the BaseX-specific XQuery options {{Code|query(:read-~ Read lock}} and {{Code|queryon CONFIG key. :write-lock}}. Multiple )declare 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 read-lock value {{Code|factbook}} will not lock a database named factbook.'CONFIG';
These option declarations will put declare function read locks on ''foo'', ''bar':config() { file:read-text(' and config.txt''batz'' and a write lock on ''quix'':)};</pre>
declare option querymodule namespace write = 'write'; (:read-~ Write lock "foo,bar";on CONFIG key. :)declare option query:readwrite-lock "batz"'CONFIG'; declare option queryfunction write:file($data) { file:write-lock "quix"text('config.txt', $data)};
→Concurrency Control
* If an updating transaction comes in, it will be queued and executed after all previous read transaction have been executed.
* 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 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.
<pre class="brush:xquery">module namespace read ==XQuery Locking Options==='read';
<pre class="brush:xquery">
</pre>
Some explanations:
* If a query is parsed that is going to call the <code>read:file</code> function, a read lock will be acquired for the user-defined {{Code|CONFIG}} lock string before query evaluation.
* If <code>write:file</code> is referenced by a query, a write lock on this lock string will be set for this query.
* If a query references <code>write:file</code>, it will be queued until there is no running query left that has {{Code|files}} locked.
* If the writing query will be 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===
