Changes

Jump to navigation Jump to search
31 bytes removed ,  17:20, 26 October 2017
* 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.
* 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. 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.
 
With {{Version|8.6}}, locking has been improved:
 
* Jobs without database access will never be locked. Globally locking jobs can now be executed in parallel with non-locking jobs.
* 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.
==XQuery Locks==
Bureaucrats, editor, reviewer, Administrators
13,550

edits

Navigation menu