bueraucrat, Bureaucrats, editor, reviewer, Administrators
907
edits
Changes
Jump to navigation
Jump to search
==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 Note:An unexpected abort of the serverduring a transaction, caused by a hardwarefailure or power cut, will probably lead to an inconsistent database state if a transaction was active at the shutdown time.So we advise to usethe [[Commands#BACKUP|BACKUP]] command to backup your database regularly. If the query is not correct, worst case occurs you can restore the transaction will not be executed,and database with the user will recieve an error message[[Commands#RESTORE|RESTORE]] command.
When executing a transaction, all updates are stored in an updatelist. They will be executed all at once, so the database isupdated atomically. If any of the update sub-transactions iserroneous, the overall transaction will be aborted.===Update Transactions===
The concurrency control checks for each transaction, which willperform Update transactions are mainly [[Update|update]] queries. When executing a read or write operation on the databaseXQuery Update query, all update operations of the status ofquery are stored in a pending updatelist. They will be executed all at once, so the lock object and decides whether the isolation database is guaranteedfor that transactionupdated atomically. If this any of the update sub-operations is the caseerroneous, the overall transaction will be started immediately.Otherwise, the transaction enters a waiting modeaborted.
With the introduction of XQuery Update the complexity of theupdate operations increased, so now it's possible to addressnumerous databases and execute updates on them. Updates, which access multiple databases cannot be executedwith a simple data lock. That's why BaseX uses a special lockobject, which controls the execution of the server process.This has the advantage that the used databases need not to beknown 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.==Concurrency Control==
For these reasonsThe concurrency control checks for each transaction, which will perform a waiting list is usedread or write operation on the database, which ensures that all processes aretreated equally the status of the lock object and executed one after another.This corresponds to decides whether the FIFO principle ('First-In First-Out'), which states isolation is guaranteed for thattransaction or not. If the first process that arrives at isolation can be guaranteed the server transaction will be started immediately. Otherwise, the transaction enters a waiting queue and waits till the transaction monitor validates and starts the first one that willbe executedtransaction. The FIFO principle cannot be adhered in a transaction monitor starts either the next writing transaction or the next group of readingtransactions, as they run in different threads and thus can overtake each other(if there are any on the queue).<br />
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:Finish]]
no edit summary
==Transaction==
In a nutshell a transaction is equal to a commandor query. So each sent command or query to the server becomes a transaction.
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
critical resource is only assigned to one writing transaction resp. a group of
reading transactions. So there is only one active writing transaction.
[[Category:Server]]
[[Category:Internal]]
