Transaction Management

From BaseX Documentation
Jump to navigation Jump to search

ACID Properties

  • Atomicity
  • Consitency
  • Isolation
  • Durability

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 subtransactions 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 uses multiple databases can not 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 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 that they are executed accordingly to their sequence. This corresponds to the FIFO principle ('First-In First-Out'), which states that the first processes that arrives at the server, will be the first one which will be executed. The FIFO principle can not 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 abort of the server during a transaction will inevitably lead to an inconsistent database. A rollback of the transaction would prevent such an undesirable database state. Unfortunately, this feature is not yet available in the current version of BaseX.