Information Technology Reference
In-Depth Information
As is seen from Algorithms 13.5 to 13.7 , when a locking protocol is used to
ensure isolation, all commit-duration locks held at server s i by a subtransaction T i
of a distributed transaction T 0 are only released after T i has committed at s i (which
occurs after T 0 has committed at the coordinating server s 0 )orafterT i has rolled
back at s i (which implies that T 0 will roll back at s 0 ). No isolation anomalies are
caused even though subtransactions T j of T 0 at servers other than s i may still be
forward-rolling when T i rolls back and releases its locks. Recall that once T i has
rolled back, all the data items updated by it have been returned to a clean state
and can hence be read and written by other transactions at s i . Also note that, when
the call prepare-to-commit .s 0 ;T 0 ;L/ (Algorithm 13.4 ) is performed at server s i in
response to a prepare-to-commit request, if the subtransaction T i of T 0 has rolled
back and hence its transaction record is no longer found in the active-transaction
table at s i , then the call returns with an “aborting” vote.
Example 13.4 Consider again the transaction of Example 13.1 . Assume that con-
currency is controlled by the multi-granular locking protocol described in Chap. 9 ,
with a three-level hierarchy of lock names: database, relation, and tuple. At each
server s i , the database at s i is IX-locked for commit duration, and the entire fragment
of the relation r at s i is X-locked for commit duration. These locks are released at
the end of the commit .T i / call.
If, on the contrary, the application requests the transaction to be rolled back
(Example 13.3 ), then the coordinator s 0 requests each server s i to abort and roll
back the subtransaction T i (Algorithm 13.7 ). At server s i the locks held by T i are
released at the end of the rollback .T i / call (Algorithms 13.6 and 4.1 ).
t
Besides deadlocks between local transactions at one server, in a distributed
database system deadlocks between subtransactions at different servers are possible.
Such deadlocks are called distributed deadlocks .
Example 13.5 The following scenario is possible in a distributed database system
with distributed transactions T 0 and T 0 0 on servers s 1 and s 2 :
1. At server s 1 , subtransaction T 1 of T 0 acquires an X lock on data item x 1 .
2. At server s 2 , subtransaction T 0 2 of T 0 0 acquires an X lock on data item x 2 .
3. At server s 1 , subtransaction T 0 1 of T 0 0 requests a lock on x 1 and hence must wait.
4. At server s 2 , subtransaction T 2 of T 0 requests a lock on x 2 and hence must wait.
Neither of the two distributed transactions can proceed, due to a distributed
deadlock: the wait by T 0 1 for T 1 at s 1 implies that T 0 0 waits for T 0 ,andthewait
by T 2 for T 0 2 at s 2 implies that T 0 waits for T 0 0 . But these waits are not seen locally:
the wait-for graph at s 1 contains only the edge T 0 1 ! T 1 and the wait-for graph at s 2
contains only the edge T 2 ! T 0 2 , so that neither graph contains any cycles.
However, interpreting the edges between subtransactions as edges between the
corresponding distributed transactions, that is, the edge T 0 1 ! T 1 as T 0 0 ! T 0 and
the edge T 2 ! T 0 2 as T 0 ! T 0 0 , and uniting the two graphs, we would get a graph
with a cycle: T 0 0 ! T 0 ! T 0 0 .
t
Search WWH ::




Custom Search