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===Options, read transactions will now be favoredPragmas, and transactions that access no databases can be evaluated even if the transactions limit has been reached.* A globally locking job can now be executed in parallel with a non-locking job.Annotations===
==External Side Effects=={{Mark|Introduced with Version 9.1}}: locks via pragmas and function annotations.
Access to external resources * 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 (files on hard disk, HTTP requests, 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.) is not controlled by * The internal locks and XQuery locks can co-exist (there will be no conflicts, even if your lock string equals the transaction monitor name of BaseX unless specified a database that will be locked by the usertransaction manager).
===XQuery Locking Options===In the following module, lock annotations are used to prevent concurrent write operations on the same file:
Custom locks can <pre class="brush:xquery">module namespace config = 'config'; declare %basex:read-lock('CONFIG') function config:read() { file:read-text('config.txt')}; declare %basex:write-lock('CONFIG') function config:write($data) { file:write-text('config.txt', $data)};</pre> Some explanations: * If a query calls the <code>config:read</code> function, a read lock will be acquired by setting for the BaseXuser-specific XQuery options defined {{Code|CONFIG}} lock string before queryevaluation.* If <code>config:read-write</code> is called by a query, a write lock on this lock}} and 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|query:write-lockCONFIG}}locked. Multiple option declarations may occur in * If the prolog of a writing querywill be evaluated, but multiple values can also be separated with commas in all other queries that will set a single declaration. These locks are in another namespace than the database names: the lock value {{Code|factbookCONFIG}} lock (reading or writing) will not have to wait. Local locks can also be declared via pragmas: <pre class="brush:xquery">(# basex:write-lock a database named factbookCONFIG #) { file:write('config.xml', <config/>)}</pre>
These Locks for the functions of a module can be assigned via option declarations will put read locks on ''foo'', ''bar'' and ''batz'' and a write lock on ''quix'':
→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|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">
declare option querybasex:readwrite-lock "foo,bar"'CONFIG';declare option query:read-lock "batz";declare option queryfile:write-lock "quix";('config.xml', <config/>)
</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
