Changes

Jump to navigation Jump to search
46 bytes removed ,  17:21, 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.
 
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.
* 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|FAIRLOCKPARALLEL}} option has been added: .* By default, read transactions will now be 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==
Bureaucrats, editor, reviewer, Administrators
13,550

edits

Navigation menu