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