Information Technology Reference
In-Depth Information
transaction T
2
later updates a tuple with key y with x
y
z
while T
1
is still
forward-rolling.
A read-only transaction cannot do any dirty read, because under transaction-level
read consistency, by definition, all the read actions read committed data. No read
action by such a transaction can be termed as an unrepeatable read either, even
though some update transaction might later, while the read-only transaction is still
active, update a tuple read by the read-only transaction. This is because read-only
transactions do no updates and, again by definition, the same read action repeated
would still read the same old version of the tuple. Thus no isolation anomalies can
occur between read-only and update transactions.
We h ave :
Theorem 12.4
Assume a history
H
of any number of forward-rolling, backward-
rolling, committed, and rolled-back transactions run at transaction-level read
consistency. If in
H
no update transaction does any dirty writes or dirty or
unrepeatable reads, then
H
is equivalent to a serial history
H
0
in which the
transactions run at transaction-level read consistency, the committed and rolled-
back update transactions commit in the same order as in
H
, and every read-only
transaction
T
is ordered before any update transaction
T
0
with start-time
.T / <
commit-time
.T
0
/
and after any update transaction
T
00
with start-time
.T /
commit-
time
.T
00
/
.
t
To ensure transaction-level read consistency, all the actions by update trans-
actions are protected by commit-duration locks. However, unlike with a single-
version database, a next-key X lock is needed only for insert actions but not for
delete actions, because deleted keys are explicitly represented as versioned tuples
.x; T;
?
/. When read actions are implemented so that they observe these tuples,
it suffices that a single X lock is acquired, namely, a commit-duration X lock on
the key to be deleted. An X lock on key x prevents other update transactions
from reading any versioned tuple with key x or creating a new version of a tuple
with key x but does not prevent a read-only transaction from reading a committed
versioned tuple with key x, because read-only transactions do not observe locks.
Example 12.5
Assume that the database contains initially the versioned tuples
.1; T
0
;
v
1
/ and .3; T
0
;
v
3
/. The following history of two update transactions T
1
and T
2
is not possible at transaction-level read consistency because of the dirty read by T
2
:
T
1
:
BD
Œ1;
v
1
DŒ2;
v
2
C
T
2
:
BR
Œx;
1;
v
I Œ2;
v
2
C
The dirty read RŒx;
1;
v
is prevented if T
1
protects the delete action DŒ1;
v
1
by
acquiring a commit-duration X lock on key 1, and T
2
observes the uncommitted
versioned tuple .1; T
1
;
?
/ and acquires an S lock on key 1.
The following history of two update transactions T
3
and T
4
is not possible at
transaction-level read consistency because of the unrepeatable read by T
3
:
T
3
:
BR
Œ3; > 1;
v
DŒ2;
v
2
C
T
4
:
BI
Œ2;
v
2
C
