Information Technology Reference
In-Depth Information
The history
T
1
: BRŒ3; > 1; 20;
v
3
::: C
T
2
: BR
Y
Œ
f
.40; 70/
g
;
f
.4; 50;
v
4
/; .5; 60;
v
5
/; .6; 60;
v
6
/
g
::: C
T
3
: BI Œ2; 50;
v
2
C
contains two isolation anomalies: both of the two read actions (whose mutual order
is irrelevant) are unrepeatable reads. In fact, in terms of the corresponding expanded
history of single-tuple actions, there are four unrepeatable reads.
The history is not possible under the key-specific key-range locking protocol,
when the transactions are run at the serializable isolation level, because T
1
protects
its read action with a commit-duration S lock on .r;X;3/ and T
2
protects its read
action with commit-duration S locks on .r;Y;50/, .r;Y;60/,and.r; Y;
1
/ and
because T
3
protects its insert action by commit-duration X locks on .r;X;2/ and
.r;Y;50/and by short-duration X locks (or IX locks) on .r;X;3/and .r;Y;60/.
t
With key-specific key-range locking, a single-tuple insert or delete action on a
relation r with primary key X and secondary keys Y
1
;:::;Y
n
requires n
C
1 commit-
duration locks and n
C
1 short-duration locks of the finest granularity, besides the
IX lock on r .
Another option is to use
primary-key-only key-range locking
(or
data-only
locking
) in which all tuple-level lock names are formed from the primary keys of
the tuples.
Example 11.2
With primary-key-only locking, the bulk-read action by transaction
T
2
in Example
11.1
is protected by commit-duration S locks on .r; 4/, .r; 5/,and
.r; 6/, and the insert action by transaction T
3
is protected by commit-duration
X locks on .r; 2/ and .r; 4/ and by short-duration X locks on .r; 3/, .r; 5/,and.r; 6/.
t
When primary-key-only locking is coupled with the partition-based locking
protocol of Sect.
10.2
, the number of locks needed can further be reduced.
11.2
Secondary B-Tree Indexes
To accelerate actions based on a secondary key, a
secondary index
to the relation
r.X;Y;V/ is constructed. Such an index is a
dense index
in that for every single
tuple .x; y;
v
/ in the relation, the secondary index contains an index record .y;x;p/
that points to the data page, p, that contains (or used to contain) the tuple and
identifies (in this case by the primary key x) the referenced tuple in the page.
We assume that the secondary index based on secondary key Y is organized as a
B-tree on the unique key composed of the pair .Y; X / of the secondary key and the
primary key. The leaf pages of this B-tree thus store the records .y;x;p/sorted first
by secondary key y and records with a duplicate secondary key sorted by primary
key x (Fig.
11.1
). For accessing the secondary index, a saved path is maintained as
for the primary sparse B-tree.
