Information Technology Reference
In-Depth Information
the transaction terminates (see Problems
1.5
and
5.9
). Revise the read-write locking
protocol so as to observe this feature.
6.9
Assume that the tuples .x; y;
v
/ of a relation r.X;Y;V/can be accessed besides
by the unique primary key x also by the (non-unique) key y (see Problems
1.6
and
5.10
). Extend the key-range locking protocol so as to cover read actions based
on non-unique keys.
6.10
Show that predicate locking with predicates “
z
<X
x,” “
z
X
x,” and
“X
D
x” prevents all the isolation anomalies defined for the key-range transaction
model.
Bibliographical Notes
Eswaran et al. [
1974
,
1976
] argue that a transaction needs to lock a logical rather
than a physical subset of the database; they present the idea of general predicate
locks. The locking protocols needed to achieve the different isolation levels for
transactions were well understood by the authors of System R [Astrahan et al.
1976
, Eswaran et al.
1974
,
1976
,Grayetal.
1975
,
1976
,
1981
]. Fine-granular (tuple-
level) locking was already applied in the logical locking protocol implemented in
System R [Astrahan et al.,
1976
]. This locking protocol also observed that when
a transaction does a partial rollback to a savepoint, all locks acquired since that
savepoint can be released [Astrahan et al.
1976
,Grayetal.
1981
]. System R is said
to have been the first database management system to do key-range locking and
guarantee serializability [Mohan,
1996a
].
The key-range locking protocol described in this chapter is a simplified version of
the
ARIES/KVL
locking protocol presented by Mohan [
1990a
] (revisited by Mohan
[
1996a
]). More specifically, our key-range locking protocol assumes that the keys
used as lock names are unique and that only the two basic lock modes S and X
are used, while
ARIES/KVL
includes locking protocols for both unique and non-
unique indexes and uses besides S and X also the intention lock mode IX (to
be discussed in Chap.
9
), thus achieving a locking protocol that permits more
concurrent histories than our simple key-range locking. Also,
ARIES/KVL
is defined
observing the underlying physical database structure (B-tree index); in particular, it
is observed that a short-duration lock requested on a data item in a data page needs
only be of “instant duration,” so that the lock is not actually inserted into the lock
table but only checked if it can be granted, provided that the data page is kept latched
during the entire action (as it is in the algorithms in Sect.
6.7
).
For reducing the number of logical locks (2n
C
1 locks for an insert action on
a relation with n indexes) needed in
ARIES/KVL
, Mohan and Levine [
1992
]defined
the
ARIES/IM
(
ARIES
for index management) locking protocol. In the “data-only
locking” variant of
ARIES/IM
, the lock names are tuple identifiers, and in the “index-
specific locking” variant, the lock names are record identifiers of index records
pointing to tuples. The original
ARIES/IM
protocol used the basic lock modes S and
