Information Technology Reference
In-Depth Information
12.6
Enforcing the Disjoint-Write Property
The disjoint-write property can be enforced with the use of commit-duration X locks
in the following way.
When transaction T wants to perform its first forward-rolling update action on
a tuple with key x (i.e., one of the actions IŒx;
v
, DŒx;
v
,orWŒx;
u
;
v
), the lock
table is examined in order to find out if some other transaction currently holds an
Xlockonx.
If no other transaction holds an X lock on x, the versioned tuple .x; T
0
;
v
0
/,if
any, is determined where T
0
is the committed transaction with the greatest
commit-
time
.T
0
/.If
commit-time
.T
0
/>
start-time
.T /;
then T
0
and T are concurrent, and since T
0
has updated x and committed, to
maintain the disjoint-write property, T must be prevented from updating x and
committing; thus T must be aborted and rolled back. Otherwise, if
commit-time
.T
0
/<
start-time
.T /;
T is allowed to read and update data items update by T
0
, so a commit-duration
Xlockonx is granted to T . The lock is also granted in the case the database does
not yet contain a versioned tuple .x; T
0
;
v
0
/.
If, on the contrary, a versioned tuple .x; T
0
;
v
0
/ exists and transaction T
0
holds
an X lock on x,thenT
0
and T are concurrent and T must wait for the outcome
of T
0
, that is, whether T
0
commits or rolls back. If T
0
commits, then, to maintain
the disjoint-write property, T and all other transactions that are also waiting for
an X lock on x must be prevented from updating x and committing; hence T
and the other waiting transactions are aborted and rolled back. Otherwise, if T
0
aborts and rolls back, T and the other transactions are allowed to wait for a lock
on x,andifT is the first in the queue, it is granted a commit-duration X lock
on x.
As with conventional locking protocols, the undo actions I
1
Œx;
v
, D
1
Œx;
v
,
and W
1
Œx;
u
;
v
are performed under the protection of the commit-duration X lock
acquired for the corresponding forward-rolling action.
Because no S locks are used to protect read actions, no read action ever waits
for an updating transaction to commit, nor does any update action wait for a read
action to complete, but update actions need to wait for an updating transaction to
commit or roll back. Transactions are aborted when their updates come too late or
after waiting for a transaction that commits.
