Transaction Management

From BaseX Documentation
Revision as of 08:57, 12 January 2011 by AW (talk | contribs)
Jump to navigation Jump to search

The BaseX client-server architecture offers ACID safe transactions, with multiple readers and single writers. Here are some more informations about the transaction management.

Transaction

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

Transaction processing

Incoming requests are parsed and checked for errors on the server. If the query is not correct, the transaction will not be executed, and the user will recieve an error message.

When executing a transaction, all updates are stored in an update list. They will be executed all at once, so the database is updated atomically. If any of the update sub-transactions is erroneous, the overall transaction will be aborted.

The concurrency control checks for each transaction, which will perform a read or write operation on the database, the status of the lock object and decides whether the isolation is guaranteed for that transaction. If this is the case, the transaction will be started immediately. Otherwise, the transaction enters a waiting mode.

With the introduction of XQuery Update the complexity of the update operations increased, so now it's possible to address numerous databases and execute updates on them. Updates, which access multiple databases cannot be executed with a simple data lock. That's why BaseX uses a special lock object, which controls the execution of the server process. This has the advantage that the used databases need not to be known in advance, and the correct execution is still granted. The disadvantage is that write operations are executed sequentially. Read-only operations are executed in parallel.

For these reasons, a waiting list is used, which ensures that all processes are treated equally and executed one after another. This corresponds to the FIFO principle ('First-In First-Out'), which states that the first process that arrives at the server will be the first one that will be executed. The FIFO principle cannot be adhered in a group of reading transactions, as they run in different threads and thus can overtake each other.

The use of the monitor also prevents the system from deadlocks, because the critical resource is only assigned to one writing transaction resp. a group of reading transactions. So there is only one active writing transaction.

N.B. An unexpected abort of the server during a transaction, caused by a hardware failure or power cut, will lead to an inconsistent database state. A rollback of the transaction would prevent such an undesirable database state. This feature is not yet available in the current version of BaseX; instead, the BACKUP and RESTORE commands can be used to create manual.