Information Technology Reference
In-Depth Information
A transaction is like a critical section, and it has
beginTransaction
and
endTransaction
statements that are similar to a critical section's
Lock::Acquire()
and
Lock::Release()
. In particular, in that transactions are isolated so that
during a transaction, the one transaction's actions cannot aect other transac-
tions. Isolation can be ensured with appropriate locking. If all of a transaction's
actions including the
endTransaction
complete, then the transaction commits,
the transaction's locks are released, and the transaction's operations become
visible.
One key difference between transactions and critical sections is that trans-
actions can abort and roll back their actions. If a transaction fails to reach its
endTransaction
statement (e.g., because of a deadlock or because some other
exception occurred), the system can reset all of the state modified by the trans-
action to what it was when the transaction began. One way to support this is to
maintain an undo log that keeps track of the initial values of all state modified
by each transaction.
So, if a transactional system becomes deadlocked, the system can abort one
or more of the deadlocked transactions. Aborting these transactions rolls back
the system's state to what it would have been if these transactions had never
started and releases the aborted transactions' locks and other resources. If
aborting the chosen transactions releases sucient resources, the deadlock is
broken and the remaining transactions can proceed. If not, then the system can
abort additional transactions.
Since aborting a transaction rolls back the state of the system to what it
would have been had the transaction not begun execution, the system can restart
the aborted transactions at some later time. For example, a conservative system
might minimize the risk of encountering the same deadlock by waiting for all
of the current (non-aborted) transactions to complete and then restarting and
completing one aborted victem transaction at a time until all of them complete.
Alternatively, a more aggressive system could restart multiple victem transac-
tions at the same time, repeating the recovery process if it gets unlucky and
deadlocks again.
Transactions with optimistic concurrency control. Instead of using trans-
actions as a way to let us break deadlocks, we can also use transactions to avoid
them. Optimistic concurrency control allows transactions to execute in parallel
Denition: Optimistic
concurrency control
without locking any data, but it only allows a transaction to commit if none
of the objects accessed by the transaction have been modified since the trans-
action began; otherwise, the transaction must abort. Typically, systems then
retry the aborted transaction|since each reexecution runs with a dierent set
of concurrent transactions, it should eventually be able to successfully commit.
One way to implement transactions with optimistic concurrency control is
for each transaction to keep track of which versions of which objects it reads
and for it to apply its updates to a local copy of each object it modifies. Then,
