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==
==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, HTTP requests, ...) is not controlled by the transaction monitor of BaseX unless specified by the user.===Query Options===
===* 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 Locking Options===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).
Custom locks can be acquired by setting In the BaseX-specific XQuery options {{Code|query:read-lock}} and {{Code|query:write-lock}}. Multiple option declarations may occur in the prolog of a queryfollowing two example modules, but multiple values can also be separated with commas in a single declaration. These locks are in another namespace than have been added to prevent concurrent write operations on the database namessame file: the lock value {{Code|factbook}} will not lock a database named factbook.
These option declarations will put <pre class="brush:xquery">module namespace read locks on = 'read'foo'', ''bar'' and ''batz'' and a write ; (:~ Read lock on CONFIG key. :)declare option query:read-lock 'CONFIG'quix; declare function read:config() { file:read-text('config.txt':)};</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)};
==Process Locking==
In order to enable locking on global (process) level, the option <code>[[Options#GLOBALLOCK|GLOBALLOCK]]</code> can be set to {{Code|true}}. This can e.g. be done by editing your {{Code|.basex}} file (see [[Options]] for more details). If process locking is active, a process that performs write operations will queue all other operations.
→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">
</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===
You can consult the query info output (which you find in the [[GUI#Visualizations|Info View]] of the GUI or which you can turn on by setting <code>[[Options#QUERYINFO|QUERYINFO]]</code> to {{Code|true}}) to find out which databases have been locked by a query.
=File-System Locks=
=Changelog=
;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.
