Bureaucrats, editor, reviewer, Administrators
13,550
edits
Changes
Jump to navigation
Jump to search
Access By default, access to external resources (files on hard disk, HTTP requests, ...) is not controlled by the transaction monitor of BaseX unless specified by the user.You can use custom XQuery locks to do so:
Custom * You can declare custom locks can be acquired by setting via the BaseX-specific XQuery options {{Code|query:read-lock}} and {{Code|query:write-lock}}. Multiple option declarations may occur options in the query prolog .* The value of a querythe option contains the lock string, but or multiple values can also be ones (separated with commas in a single declaration). 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 In the following two example modules, locks on ''foo'', ''bar'' and ''batz'' and a have been added to prevent concurrent write lock operations on ''quix''the same file:
→Query Options
* 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.
==External Side EffectsXQuery Locks==
===XQuery Locking Query Options===
<pre class="brush:xquery">
module namespace read = 'read'; (:~ Read lock on CONFIG key. :)declare option query:read-lock "foo,bar"'CONFIG'; declare option queryfunction read:config() { file:read-lock text('config.txt')};</pre> <pre class="batzbrush:xquery">module namespace write = 'write'; (:~ Write lock on CONFIG key. :)declare option query:write-lock "quix"'CONFIG'; declare function write:file($data) { file:write-text('config.txt', $data)};
</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===
