Difference between revisions of "Transaction Management"

From BaseX Documentation
Jump to navigation Jump to search
(32 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
This article is part of the [[Advanced User's Guide]].
 
This article is part of the [[Advanced User's Guide]].
The BaseX client-server architecture offers ACID safe transactions,
+
The BaseX client-server architecture offers ACID-safe transactions,
with multiple readers and writers. Here are some more
+
with multiple readers and writers. Here is some more
informations about the transaction management.
+
information about the transaction management.
  
=Transaction=
+
=Introduction=
  
 
In a nutshell, a transaction is equal to a command or query. So each command or query sent to the server becomes a transaction.
 
In a nutshell, a transaction is equal to a command or query. So each command or query sent to the server becomes a transaction.
  
Incoming requests are parsed and checked for errors on the server. If the command or query is not correct, the request will not be executed,
+
Incoming requests are parsed and checked for errors on the server. If the command or query is not correct, the request will not be executed, and the user will receive an error message. Otherwise the request becomes a transaction and gets into the transaction monitor.
and the user will receive an error message. Otherwise the request becomes a transaction and gets into the transaction monitor.
 
  
Note:
+
Please note that:
An unexpected abort of the server during a transaction, caused by a hardware
 
failure or power cut, may lead to an inconsistent database state if a transaction was active at the shutdown time. So we advise to use
 
the [[Commands#CREATE BACKUP|BACKUP]] command to backup your database regularly. If the worst case occurs, you can try the [[Commands#INSPECT|INSPECT]] command to check if your database has obvious inconsistencies, and [[Commands#RESTORE|RESTORE]] to restore a previous version of the database.
 
  
==Update Transactions==
+
* Locks ''cannot be synchronized'' across BaseX instances that run in different JVMs. If concurrent write operations are to be performed, we generally recommend working with the client/server or the HTTP architecture .
 +
* An ''unexpected abort'' of the server during a transaction, caused by a hardware failure or power cut, may lead to an inconsistent database state if a transaction was active at shutdown time. So it is advisable to use the [[Commands#CREATE BACKUP|BACKUP]] command to regularly backup your database. If the worst case occurs, you can try the [[Commands#INSPECT|INSPECT]] command to check if your database has obvious inconsistencies, and use [[Commands#RESTORE|RESTORE]] to restore the last backed up version of the database.
 +
 
 +
==XQuery Update==
  
 
Many update operations are triggered by [[Update|XQuery Update]] expressions. When executing an updating query, all update operations of the query are stored in a pending update list. They will be executed all at once, so the database is updated atomically. If any of the update sub-operations is erroneous, the overall transaction will be aborted.
 
Many update operations are triggered by [[Update|XQuery Update]] expressions. When executing an updating query, all update operations of the query are stored in a pending update list. They will be executed all at once, so the database is updated atomically. If any of the update sub-operations is erroneous, the overall transaction will be aborted.
Line 22: Line 21:
 
=Concurrency Control=
 
=Concurrency Control=
  
BaseX provides locking on database level. Writing transactions do not necessarily block all other transactions any more. The number of parallel transactions can be limited by setting the [[Options#PARALLEL|PARALLEL]] option.
+
BaseX provides support for multiple read and single write operations (using preclaiming and starvation-free two phase locking). This means that:
  
==Transaction Monitor==
+
* Read transactions are executed in parallel.
 +
* 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.
  
The transaction monitor ensures that just one writing transaction or an arbitrary amount of reading transactions ''per database'' are active at the same time.
+
==XQuery Locks==
  
Deadlocks are prevented by using preclaiming two phase locking. Execution is starvation-free as lock acquisition is queued per database. Due to the specifics of XQuery Update, all updates are written at the end of the query. Locking is strict with the exception that databases for which BaseX recognizes it will not write to are downgraded to read locks.
+
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:
  
Locks are not synchronized between multiple BaseX instances. We generally recommend working with the client/server architecture if concurrent write operations are to be performed.
+
===Query Options===
  
==External Side Effects==
+
* 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 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).
  
Access to external resources (files on hard disk, HTTP requests, ...) is not controlled by BaseX' transaction monitor unless specified by the user.
+
In the following two example modules, locks have been added to prevent concurrent write operations on the same file:
  
===XQuery Locking Options===
+
<pre class="brush:xquery">
 +
module namespace read = 'read';
  
Custom locks can be acquired by setting the BaseX-specific XQuery options {{Code|query:read-lock}} and {{Code|query:write-lock}}. Multiple option declaration may occur in the prolog of a query, but multiple values can also be separated with commas in a single declaration. These locks are in another namespace than the database names: the lock value {{Code|factbook}} will not lock a database named factbook.
+
(:~ Read lock on CONFIG key. :)
 +
declare option query:read-lock 'CONFIG';
  
These option declarations will put read locks on ''foo'', ''bar'' and ''batz'' and a write lock on ''quix''.
+
declare function read:config() {
 +
  file:read-text('config.txt')
 +
};
 +
</pre>
  
 
<pre class="brush:xquery">
 
<pre class="brush:xquery">
declare option query:read-lock "foo,bar";
+
module namespace write = 'write';
declare option query:read-lock "batz";
+
 
declare option query:write-lock "quix";
+
(:~ Write lock on CONFIG key. :)
 +
declare option query:write-lock 'CONFIG';
 +
 
 +
declare function write:file($data) {
 +
  file:write-text('config.txt', $data)
 +
};
 
</pre>
 
</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===
 
===Java Modules===
  
Since {{Version|7.8}}, locks can also be acquired on [[Java Bindings#Java functions|Java functions]] invoked from XQuery expressions. It is advisable to explicitly lock Java code whenever it performs sensitive read and write operations.
+
Locks can also be acquired on [[Java Bindings#Locking|Java functions]] which are imported and invoked from an XQuery expression. It is advisable to explicitly lock Java code whenever it performs sensitive read and write operations.
  
 
==Limitations==
 
==Limitations==
Line 56: Line 83:
 
===Commands===
 
===Commands===
  
Database locking works with all commands unless no glob syntax is used, such as in the following command call:
+
Database locking works with all commands unless the glob syntax is used, such as in the following command call:
  
 
* {{Code|DROP DB new*}}: drop all databases starting with "new"
 
* {{Code|DROP DB new*}}: drop all databases starting with "new"
Line 62: Line 89:
 
===XQuery===
 
===XQuery===
  
As XQuery is a very powerful language, deciding which databases will be accessed by a query is non-trivial. Optimization is work in progress.
+
Deciding which databases will be accessed by a complex XQuery expression is a non-trivial task. Database detection works for the following types of queries:
The current identification of which databases to lock is limited to queries that access the currently opened database, XQuery functions that explicitly specify a database, and expressions that address no database at all.
 
 
 
Some examples on database-locking enabled queries, all of these can be executed in parallel:
 
  
 
* {{Code|//item}}, read-locking of the database opened by a client
 
* {{Code|//item}}, read-locking of the database opened by a client
Line 73: Line 97:
 
* {{Code|delete nodes doc('test')//*[string-length(local-name(.)) > 5]}}, write-locking of "test"
 
* {{Code|delete nodes doc('test')//*[string-length(local-name(.)) > 5]}}, write-locking of "test"
  
Some examples on queries that are not supported by database-locking yet:
+
All databases will be locked by queries of the following kind:
  
* <code>let $db := 'factbook' return doc($db)</code>, will read-lock: referencing database names isn’t supported yet
+
* {{Code|for $db in ('db1', 'db2') return doc($db)}}
* {{Code|for $db in ('factbook') return doc($db)}}, will read-lock globally
+
* {{Code|doc(doc('test')/reference/text())}}
* {{Code|doc(doc('test')/reference/text())}}, will read-lock globally
+
* <code>let $db := 'test' return insert nodes <test/> into doc($db)</code>
* <code>let $db := 'test' return insert nodes <test/> into doc($db)</code>, will write-lock globally
 
  
A list of all locked databases is output if <code>[[Options#QUERYINFO|QUERYINFO]]</code> is set to {{Code|true}}. <!-- and in the GUI's [[GUI#Visualizations|Info View]] --> If you think that too much is locked, please give us a note on our [http://basex.org/open-source/ mailing list] with some example code.
+
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.
 
 
===GUI===
 
 
 
Database locking is currently disabled if the BaseX GUI is used.
 
 
 
==How to disable==
 
 
 
In order to disable traditional process locking, the option <code>[[Options#GLOBALLOCK|GLOBALLOCK]]</code> can be set to {{Code|false}}. This can e.g. be done by editing your {{Code|.basex}} file (see [[Options]] for more details). To enable it again, set it to {{Code|true}}.
 
  
 
=File-System Locks=
 
=File-System Locks=
Line 94: Line 109:
 
==Update Operations==
 
==Update Operations==
  
During the term of a database update, a locking file {{Code|upd.basex}} will reside in that database directory. If the update fails for some unexpected reason, or if the process is killed ungracefully, this file may not be deleted. In this case, the database cannot be opened anymore using the default commands, and the message "Database ... is being updated, or update was not completed" will be shown instead. If the locking file is manually removed, you may be able to reopen the database, but you should be aware that database may have got corrupt due to the interrupted update process, and you should revert to the most recent database backup.
+
During a database update, a locking file {{Code|upd.basex}} will reside in that database directory. If the update fails for some unexpected reason, or if the process is killed ungracefully, this file will not be deleted. In this case, the database cannot be opened anymore, and the message "Database ... is being updated, or update was not completed" will be shown instead.  
 +
 
 +
If the locking file is manually removed, you may be able to reopen the database, but you should be aware that database may have got corrupt due to the interrupted update process, and you should revert to the most recent database backup.
  
 
==Database Locks==
 
==Database Locks==
  
To avoid database corruptions caused by write operations running in different JVMs, a shared lock is requested on the database table file ({{Code|tbl.basex}}) whenever a database is opened. If an update operation is triggered, it will be rejected with the message "Database ... is opened by another process." if no exclusive lock can be acquired.
+
To avoid database corruptions that are caused by accidental write operations from different JVMs, a shared lock is requested on the database table file ({{Code|tbl.basex}}) whenever a database is opened. If an update operation is triggered, and if no exclusive lock can be acquired, it will be rejected with the message "Database ... is currently opened by another process.".
  
As the standalone versions of BaseX (command-line, GUI) cannot be synchronized with other BaseX instances, we generally recommend working with the client/server architecture if concurrent write operations are to be performed.
+
Please note that you cannot 100% rely on this mechanism, as it is not possible to synchronize operations across different JVMs. You will be safe when using the client/server or HTTP architecture.
  
 
=Changelog=
 
=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
 
;Version 7.6
 
+
* Added: database locking introduced, replacing process locking.
* Added: database locking introduced, replacing process locking
 
  
 
;Version 7.2.1
 
;Version 7.2.1
 
+
* Updated: pin files replaced with shared/exclusive filesystem locking.
* Updated: pin files replaced with shared/exclusive filesystem locking
 
  
 
;Version 7.2
 
;Version 7.2
 
+
* Added: pin files to mark open databases.
* Added: pin files to mark open databases
 
  
 
;Version 7.1
 
;Version 7.1
 
+
* Added: update lock files.
* Added: update lock files
 
 
 
[[Category:Server]]
 
[[Category:Internals]]
 

Revision as of 16:21, 26 October 2017

This article is part of the Advanced User's Guide. The BaseX client-server architecture offers ACID-safe transactions, with multiple readers and writers. Here is some more information about the transaction management.

Introduction

In a nutshell, a transaction is equal to a command or query. So each command or query sent to the server becomes a transaction.

Incoming requests are parsed and checked for errors on the server. If the command or query is not correct, the request will not be executed, and the user will receive an error message. Otherwise the request becomes a transaction and gets into the transaction monitor.

Please note that:

  • Locks cannot be synchronized across BaseX instances that run in different JVMs. If concurrent write operations are to be performed, we generally recommend working with the client/server or the HTTP architecture .
  • An unexpected abort of the server during a transaction, caused by a hardware failure or power cut, may lead to an inconsistent database state if a transaction was active at shutdown time. So it is advisable to use the BACKUP command to regularly backup your database. If the worst case occurs, you can try the INSPECT command to check if your database has obvious inconsistencies, and use RESTORE to restore the last backed up version of the database.

XQuery Update

Many update operations are triggered by XQuery Update expressions. When executing an updating query, all update operations of the query are stored in a pending update list. They will be executed all at once, so the database is updated atomically. If any of the update sub-operations is erroneous, the overall transaction will be aborted.

Concurrency Control

BaseX provides support for multiple read and single write operations (using preclaiming and starvation-free two phase locking). This means that:

  • Read transactions are executed in parallel.
  • 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 below).
  • The number of maximum parallel transactions can be adjusted with the 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 FAIRLOCK option.

XQuery Locks

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:

Query Options

  • You can declare custom locks via the query:read-lock and 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 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).

In the following two example modules, locks have been added to prevent concurrent write operations on the same file:

module namespace read = 'read';

(:~ Read lock on CONFIG key. :)
declare option query:read-lock 'CONFIG';

declare function read:config() {
  file:read-text('config.txt')
};
module namespace write = 'write';

(:~ Write lock on CONFIG key. :)
declare option query:write-lock 'CONFIG';

declare function write:file($data) {
  file:write-text('config.txt', $data)
};

Some explanations:

  • If a query is parsed that is going to call the read:file function, a read lock will be acquired for the user-defined CONFIG lock string before query evaluation.
  • If write:file is referenced by a query, a write lock on this lock string will be set for this query.
  • If a query references write:file, it will be queued until there is no running query left that has files locked.
  • If the writing query will be evaluated, all other queries that will set a files lock (reading or writing) will have to wait.

In practice, it’s often sufficient to only work with (exclusive) write locks.

Java Modules

Locks can also be acquired on Java functions which are imported and invoked from an XQuery expression. It is advisable to explicitly lock Java code whenever it performs sensitive read and write operations.

Limitations

Commands

Database locking works with all commands unless the glob syntax is used, such as in the following command call:

  • DROP DB new*: drop all databases starting with "new"

XQuery

Deciding which databases will be accessed by a complex XQuery expression is a non-trivial task. Database detection works for the following types of queries:

  • //item, read-locking of the database opened by a client
  • doc('factbook'), read-locking of "factbook"
  • collection('db/path/to/docs'), read-locking of "db"
  • fn:sum(1 to 100), locking nothing at all
  • delete nodes doc('test')//*[string-length(local-name(.)) > 5], write-locking of "test"

All databases will be locked by queries of the following kind:

  • for $db in ('db1', 'db2') return doc($db)
  • doc(doc('test')/reference/text())
  • let $db := 'test' return insert nodes <test/> into doc($db)

You can consult the query info output (which you find in the Info View of the GUI or which you can turn on by setting QUERYINFO to true) to find out which databases have been locked by a query.

File-System Locks

Update Operations

During a database update, a locking file upd.basex will reside in that database directory. If the update fails for some unexpected reason, or if the process is killed ungracefully, this file will not be deleted. In this case, the database cannot be opened anymore, and the message "Database ... is being updated, or update was not completed" will be shown instead.

If the locking file is manually removed, you may be able to reopen the database, but you should be aware that database may have got corrupt due to the interrupted update process, and you should revert to the most recent database backup.

Database Locks

To avoid database corruptions that are caused by accidental write operations from different JVMs, a shared lock is requested on the database table file (tbl.basex) whenever a database is opened. If an update operation is triggered, and if no exclusive lock can be acquired, it will be rejected with the message "Database ... is currently opened by another process.".

Please note that you cannot 100% rely on this mechanism, as it is not possible to synchronize operations across different JVMs. You will be safe when using the client/server or HTTP architecture.

Changelog

Version 8.6
  • Updated: New FAIRLOCK option, improved detection of lock patterns.
Version 7.8
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.