Information Technology Reference
In-Depth Information
transaction in groups 1 and 3 contains a list of the identifiers of all the participants
of the transaction. A group 1 transaction has no prepare-to-commit log record in the
log, but the record for the transaction in the active-transaction table reconstructed in
the analysis pass contains the list of participants, because each addition to the list
was logged.
As long as the fates of the in-doubt (group 4) transactions are not known,
those transactions must remain in the prepared-to-commit state at s
i
, implying
that their uncommitted updates must be protected from dirty reads and dirty
writes by new transactions that access server s
i
after its recovery. With lock-based
concurrency control, appropriate commit-duration locks must be acquired. This is
done by scanning the log at s
i
backwards along the
U
NDO
-N
EXT
-LSN
chains in search
for logged updates by in-doubt transactions. To make possible the acquiring of
appropriate locks in this way, the log records for the updates must carry sufficient
information about the lock names required. For example, with the key-range locking
protocol, the lock name for the key y next to the key x of a deleted tuple .x;
v
/ must
be included in the log record for the deletion, so that a commit-duration X lock can
be acquired on y.
For each in-doubt (or group 4) subtransaction T
i
, the fate of the distributed
transaction T
0
must be inquired from the coordinator of T
0
or from one of the other
participants. Recall that the reconstructed transaction record for such a subtransac-
tion T
i
contains the identifiers of the parent transaction T
0
, the coordinator s
0
,and
of the other participants.
In our simple variant of the two-phase commit protocol, a log scan is possibly
needed to respond to such an inquiry. This is because both of the calls
commit
.T
i
/
and
rollback
.T
i
/ performed in Algorithms
13.5
and
13.6
remove the transaction
record for T
i
from the active-transaction table, as well as the locks held by T
i
from
the lock table, so that no trace of T
i
remains in the main-memory data structures. In
the Problems section, we consider a practical variant, called
presumed abort
,ofthe
two-phase commit protocol, in which the nonexistence of the transaction record of
T
i
in the active-transaction table of the coordinator implies that T
i
has aborted.
13.6
Isolation and Concurrency Control
The isolation concepts considered in Chap.
5
for a centralized database system
readily generalize to a distributed database system. For example, an update action
WŒxby subtransaction T
i
of a distributed transaction T
0
is a dirty write if the data
item x has an uncommitted update by some subtransaction T
0
j
of another distributed
transaction T
0
0
. Similarly, we can generalize the isolation anomalies dirty read and
unrepeatable read. Using these generalized definitions for the isolation anomalies,
we can define
SQL
isolation levels for distributed transactions in the obvious way.
We assume that each server controls the concurrency of actions on its own data
items with one of the concurrency-control mechanisms defined previously for a cen-
tralized database system. Accordingly, each server s
i
ensures isolation for its local
transactions and for any subtransactions of distributed transactions running at s
i
.
