Bureaucrats, editor, reviewer, Administrators
13,550
edits
Changes
Jump to navigation
Jump to search
Each database has its own queue<pre class="brush: 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">module namespace config = 'config';
With declare %basex:read-lock('CONFIG') function config:read() {{Version|8 file:read-text('config.6txt')}}, locking has been improved:;
* Jobs without database access will never be locked. Globally locking jobs can now be executed in parallel with nondeclare %basex:write-lock('CONFIG') function config:write($data) { file:write-locking jobstext('config.txt', $data)* 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 transactions limit has been reached.;</pre>
==External Side Effects==Some explanations:
Access to external resources (files on hard disk* If a query calls the <code>config:read</code> function, HTTP requestsa 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) is not controlled by the transaction monitor of BaseX unless specified by the userwill have to wait.
===XQuery Locking Options===Local locks can also be declared via pragmas:
Custom locks can be acquired by setting the BaseX-specific XQuery options {{Code|query<pre class="brush:xquery">(# basex:readwrite-lock}} and CONFIG #) {{Code|query file:write-lock}}('config. Multiple option declarations may occur in the prolog of a queryxml', but multiple values can also be separated with commas in a single declaration. These locks are in another namespace than the database names: the lock value {{Code|factbook<config/>)}} will not lock a database named factbook.</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.
==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:
===Options, Pragmas, Annotations===
{{Mark|Introduced with Version 9.1}}: locks via pragmas and function 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, lock annotations are used to prevent concurrent write operations on the same file:
<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
