Difference between revisions of "Transaction Management"

From BaseX Documentation
Jump to navigation Jump to search
Line 4: Line 4:
 
==Transaction==
 
==Transaction==
  
−
In a nutshell a transaction is equal to a command. So each sent command to the server becomes a transaction.
+
In a nutshell a transaction is equal to a command or query. So each sent command or query to the server becomes a transaction.
  
−
==Transaction processing==
+
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 recieve an error message. Otherwise the request becomes a transaction and gets into the transaction monitor.
  
−
Incoming requests are parsed and checked for errors on the server.
+
Note:
−
If the query is not correct, the transaction will not be executed,
+
An unexpected abort of the server during a transaction, caused by a hardware
−
and the user will recieve an error message.
+
failure or power cut, will probably lead to an inconsistent database state if a transaction was active at the shutdown time. So we advise to use
 +
the [[Commands#BACKUP|BACKUP]] command to backup your database regularly. If the worst case occurs you can restore the database with the [[Commands#RESTORE|RESTORE]] command.
  
−
When executing a transaction, all updates are stored in an update
+
===Update Transactions===
−
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
+
Update transactions are mainly [[Update|update]] queries. When executing a XQuery Update query, all update operations of the query are stored in a pending update
−
perform a read or write operation on the database, the status of
+
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.
−
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
+
==Concurrency Control==
−
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
+
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 or not. If the isolation can be guaranteed the transaction will be started immediately. Otherwise, the transaction enters a waiting queue and waits till the transaction monitor validates and starts the transaction. The transaction monitor starts either the next writing transaction or the next group of reading transactions (if there are any on the queue).<br />
−
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 transaction monitor ensures that just one writing transaction is active at the same time. This seems to be an odd mechanism, but it is needed since the complexity of updates increased and it is possible now to access multiple databases in one XQuery Update query.<br />
 +
For avoiding the starving of any transaction and wrong execution orders the waiting queue works with 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.<br/>
 
The use of the monitor also prevents the system from deadlocks, because the  
 
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
 
critical resource is only assigned to one writing transaction resp. a group of
 
reading transactions. So there is only one active writing transaction.
 
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 [[Commands#BACKUP|BACKUP]] and [[Commands#RESTORE|RESTORE]] commands can
 
−
be used to create manual.
 
  
 
[[Category:Server]]
 
[[Category:Server]]
 
[[Category:Internal]]
 
[[Category:Internal]]
−
[[Category:Finish]]
 

Revision as of 10:16, 12 January 2011

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 or query. So each sent command or query 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 recieve an error message. Otherwise the request becomes a transaction and gets into the transaction monitor.

Note: An unexpected abort of the server during a transaction, caused by a hardware failure or power cut, will probably lead to an inconsistent database state if a transaction was active at the shutdown time. So we advise to use the BACKUP command to backup your database regularly. If the worst case occurs you can restore the database with the RESTORE command.

Update Transactions

Update transactions are mainly update queries. When executing a XQuery Update 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

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 or not. If the isolation can be guaranteed the transaction will be started immediately. Otherwise, the transaction enters a waiting queue and waits till the transaction monitor validates and starts the transaction. The transaction monitor starts either the next writing transaction or the next group of reading transactions (if there are any on the queue).

The transaction monitor ensures that just one writing transaction is active at the same time. This seems to be an odd mechanism, but it is needed since the complexity of updates increased and it is possible now to access multiple databases in one XQuery Update query.
For avoiding the starving of any transaction and wrong execution orders the waiting queue works with 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.

Retrieved from "http://docs.basex.org/index.php?title=Transaction_Management&oldid=1569"