Information Technology Reference
In-Depth Information
A similar situation happens with transactions
T
1
D
BD
Œx;
u
and
T
2
D
BI
Œx;
u
C
and the history
H
2
D
T
1
:
BD
Œx; 0
T
2
:
BI
Œx; 0C .
The completed history
AD
1
Œx; 0C
H
0
2
D
T
1
:
BD
Œx; 0
T
2
:
BI
Œx; 0C .
cannot be run on any database D on which H can be run. The action IŒx;0 by the
committed transaction T
2
is a dirty write.
t
The examples above clearly suggest that dirty writes are incompatible with
transaction rollback and should therefore be prevented. The situations in which
transaction rollback might still be possible in the presence of dirty writes are difficult
or even impossible for the database management system to detect automatically, as
is demonstrated in the following example.
Example 5.23
Consider the following history of two forward-rolling transactions
T
1
D
BW
Œx;
u
;1 and T
2
D
BW
Œx;
u
;2:
H
D
T
1
:
BW
Œx;0;1
T
2
:
BW
Œx;1;2
Here W Œx; 1; 2 is a dirty write. Now both transactions wish to abort. The rollback
will succeed if the undo actions of the writes are performed in reverse chronological
order, that is, the rollback of T
2
is followed by the rollback of T
1
:
H
0
1
D
T
1
:
BW
Œx;0;1 A W
1
Œx;0;1C
T
2
:
BW
Œx;1;2
AW
1
Œx;1;2 C
(where the relative order between the two A actions or between the two C actions
does not matter). However, rolling back the write by T
1
first would lead to a history
that is not runnable according to our definitions:
H
0
2
D
T
1
:
BW
Œx;0;1
AW
1
Œx;0;1C
T
2
:
BW
Œx;1;2
AW
1
Œx;1;2C
Even if we defined WŒx;
u
;
v
to be always runnable on a database with a tuple with
key x (even though its value might be different from
u
), the rollback would produce
a database state that differs from the original.
t
Theorem 5.24
Let
H
be a history in which none of the committed or rolled-
back transactions do dirty writes. The action sequences that complete the active
transactions in
H
to rolled-back transactions can be interleaved to a sequence
so that the completed sequence
H
can be run on every database where
H
can
