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.
With {{Version|8.6}}, locking has been improved:
* The locks are declared as options {{CodeMark|query:read-lockIntroduced with Version 9.1}} and {{Code|query:write-lock}} in the query prolog.* Multiple option declarations can be specified in a module, or values can also be separated with commas in a single declaration.* XQuery locks are in a separate namespace, such that there will be no conflicts with the internal database locks.* Similar to internal locks, write locks block all other operations while read locks allow parallel accessvia pragmas and function annotations.
(:~ Write lock for all functions of the module. :)declare option query%basex:writeread-lock "files";('CONFIG') function config:~ Config file. :read(){declare variable $config: file := read-text('config.txt')};
declare function configLocal locks can also be declared via pragmas: <pre class="brush:readxquery">(# basex:write-lock CONFIG #) { file:read-textwrite($'config.xml', <config:file/>)}</pre> Locks for the functions of a module can be assigned via option declarations: <pre class="brush:xquery">declare option basex:write-lock 'CONFIG';file:write('config.xml', <config/>)
→Options, Pragmas, Annotations
* 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|FAIRLOCKPARALLEL}} option has been added: .* 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.
==XQuery Locks==
By default, access to external resources (files on hard disk, HTTP requests, ...) is not controlled by the transaction monitor of BaseX. You can use custom XQuery locks to do so:
===Query Options, Pragmas, Annotations===
* You can declare custom read and write locks via options, pragmas or function annotations.* The value of the lock may contain one 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 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). In the following module, a write lock is declared annotations are used to avoid multiple clients writing to a config file at prevent concurrent write operations on the same timefile:
<pre class="brush:xquery">
module namespace config = 'config';
declare %basex:write-lock('CONFIG') function config:write($configdata) { file:write-text($'config:file.txt', $configdata)
};
</pre>
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 on this lock string will be set for this query.
* If a 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 query will be evaluated, all other queries that will set a {{Code|CONFIG}} lock (reading or writing) will have to wait.
</pre>
Before {{Version|9.1}}, locks were declared in the {{Code|query}} namespace.
===Java Modules===
=Changelog=
;Version 9.1
* Updated: Query lock options were moved from {{Code|query}} to {{Code|basex}} namespace.
;Version 8.6
