Changes

Jump to navigation Jump to search
1,861 bytes added ,  19:22, 20 August 2018
* 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.
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==
==External Side Effects==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:
Access to external resources (files on hard disk===Options, HTTP requestsPragmas, ...) is not controlled by the transaction monitor of BaseX unless specified by the user.Annotations===
===XQuery Locking Options==={{Mark|Introduced with Version 9.1}}: locks via pragmas and function annotations.
Custom locks * You can be acquired by setting the BaseX-specific XQuery options {{Code|query:declare custom read-lock}} and {{Code|query:write-locks via options, pragmas or function annotations.* The value of the lock}}. Multiple option declarations may occur in the prolog of a query, but contain one or multiple values can also be lock keys (separated with commas in a single declaration). The default value is an empty string. These locks are in another namespace than * Similar to the internal database names: the lock value {{Code|factbook}} locks, write locks block all other operations while read locks allow parallel access.* The internal locks and XQuery locks can co-exist (there will not be no conflicts, even if your lock string equals the name of a database named factbookthat will be locked by the transaction manager).
These option declarations will put read locks on ''foo''In the following module, ''bar'' and ''batz'' and a lock annotations are used to prevent concurrent write lock operations on ''quix''the same file:
<pre class="brush:xquery">
module namespace config = 'config'; declare option query%basex:read-lock('CONFIG') function config:read() { file:read-text('config.txt')}; declare %basex:write-lock "foo('CONFIG') function config:write($data) { file:write-text('config.txt',bar"$data)};declare option </pre> Some explanations: * If a querycalls 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. Local locks can also be declared via pragmas: <pre class="brush:xquery">(# basex:write-lock CONFIG #) { file:write('config.xml', <config/>)}</pre> Locks for the functions of a module can be assigned via option declarations: <pre class="batzbrush:xquery";>declare option querybasex:write-lock "quix"'CONFIG';file:write('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
* Updated: New {{Option|FAIRLOCK}} option, improved detection of lock patterns.
;Version 7.8
 
* Added: Locks can also be acquired on [[Java Bindings#Locking|Java functions]].
;Version 7.6
 
* Added: database locking introduced, replacing process locking.
;Version 7.2.1
 
* Updated: pin files replaced with shared/exclusive filesystem locking.
;Version 7.2
 
* Added: pin files to mark open databases.
;Version 7.1
 
* Added: update lock files.
Bureaucrats, editor, reviewer, Administrators
13,550

edits

Navigation menu