Difference between revisions of "Transaction Management"
| Line 7: | Line 7: | ||
When executing a transaction, all updates are stored in an update | When executing a transaction, all updates are stored in an update | ||
list. They will be executed all at once, so the database is | list. They will be executed all at once, so the database is | ||
| − | updated atomically. If any of the update | + | updated atomically. If any of the update sub-transactions is |
| − | erroneous the overall transaction will be aborted. | + | erroneous, the overall transaction will be aborted. |
The concurrency control checks for each transaction, which will | The concurrency control checks for each transaction, which will | ||
| Line 20: | Line 20: | ||
update operations increased, so now it's possible to address | update operations increased, so now it's possible to address | ||
numerous databases and execute updates on them. | numerous databases and execute updates on them. | ||
| − | Updates, which | + | Updates, which access multiple databases cannot be executed |
with a simple data lock. That's why BaseX uses a special lock | with a simple data lock. That's why BaseX uses a special lock | ||
object, which controls the execution of the server process. | object, which controls the execution of the server process. | ||
This has the advantage that the used databases need not to be | This has the advantage that the used databases need not to be | ||
| − | known and the correct execution is still granted. The | + | known in advance, and the correct execution is still granted. The |
disadvantage is that write operations are executed sequentially. | disadvantage is that write operations are executed sequentially. | ||
Read-only operations are executed in parallel. | Read-only operations are executed in parallel. | ||
For these reasons, a waiting list is used, which ensures that all processes are | For these reasons, a waiting list is used, which ensures that all processes are | ||
| − | treated equally and | + | treated equally and executed one after another. |
This corresponds to the FIFO principle ('First-In First-Out'), which states that | This corresponds to the FIFO principle ('First-In First-Out'), which states that | ||
| − | the first | + | the first process that arrives at the server will be the first one that will |
| − | be executed. The FIFO principle | + | be executed. The FIFO principle cannot be adhered in a group of reading |
| − | transactions, as they run in different threads and thus | + | 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 | 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. | N.B. | ||
An abort of the server during a transaction will inevitably lead | An abort of the server during a transaction will inevitably lead | ||
to an inconsistent database. A rollback of the transaction would | to an inconsistent database. A rollback of the transaction would | ||
| − | prevent such an undesirable database state. | + | prevent such an undesirable database state. This feature is not |
| − | + | yet available in the current version of BaseX. | |
[[Category:Server]] | [[Category:Server]] | ||
[[Category:Internal]] | [[Category:Internal]] | ||
[[Category:Finish]] | [[Category:Finish]] | ||
Revision as of 01:57, 18 December 2010
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 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. This feature is not yet available in the current version of BaseX.
