Multiple Granularity

 Allow data items to be of various sizes and define a

hierarchy of data granularities, where the small
granularities are nested within larger ones
 Can be represented graphically as a tree (but don't
confuse with tree-locking protocol)
 When a transaction locks a node in the tree explicitly, it
implicitly locks all the node's descendents in the same
mode.
 Granularity of locking (level in tree where locking is
done):
 fine granularity (lower in tree): high concurrency,
high locking overhead
 coarse granularity (higher in tree): low locking
overhead, low concurrency
12/9/2009 2
 Example of Granularity
Hierarchy

The highest level in the example hierarchy is the entire database.

The levels below are of type area, file and record in that order.
12/9/2009 3
 Intention Lock Modes
 In addition to S and X lock modes, there are three
additional lock modes with multiple granularity:
 intention-shared (IS): indicates explicit locking at a
lower level of the tree but only with shared locks.
 intention-exclusive (IX): indicates explicit locking at
a lower level with exclusive or shared locks
 shared and intention-exclusive (SIX): the subtree
rooted by that node is locked explicitly in shared
mode and explicit locking is being done at a lower
level with exclusive-mode locks.
 intention locks allow a higher level node to be locked in
S or X mode without having to check all descendent
nodes.

12/9/2009 4
 Compatibility Matrix with
Intention Lock Modes
 The compatibility matrix for all lock modes is:

IS IX S S IX X
IS     ×

IX   × × ×

S  ×  × ×

S IX  × × × ×

X × × × × ×

12/9/2009 5
 Multiple Granularity Locking
Scheme
 Transaction Ti can lock a node Q, using the following
rules:
1. The lock compatibility matrix must be observed.
2. The root of the tree must be locked first, and may be
locked in any mode.
3. A node Q can be locked by Ti in S or IS mode only
if the parent of Q is currently locked by Ti in either
IX or IS mode.
4. A node Q can be locked by Ti in X, SIX, or IX mode
only if the parent of Q is currently locked by Ti in
either IX or SIX mode.
12/9/2009 6
 5. Ti can lock a node only if it has not
previously unlocked any node (that is, Ti
is two-phase).
6. Ti can unlock a node Q only if none of
the children of Q are currently locked by
Ti.
 Observe that locks are acquired in root-
to-leaf order,
whereas they are released in leaf-to-root
order.

12/9/2009 7
 Deadlock Handling

 Consider the following two transactions:

T1: write (X) T2: write(Y)
write(Y) write(X)
 Schedule with deadlock
T1 T2

lock-X on X
write (X)
lock-X on Y
write (X)
wait for lock-X on X
wait for lock-X on Y

12/9/2009 8
 Deadlock Handling

 System is deadlocked if there is a set of

transactions such that every transaction in the
set is waiting for another transaction in the set.
 Deadlock prevention protocols ensure that the
system will never enter into a deadlock state.
Some prevention strategies :
 Require that each transaction locks all its
data items before it begins execution
(predeclaration).
 Impose partial ordering of all data items and
require that a transaction can lock data items
only in the order specified by the partial
12/9/2009
order (graph-based protocol). 9
 More Deadlock Prevention
Strategies
 Following schemes use transaction timestamps for the
 sake of deadlock prevention alone.
 wait-die scheme — non-preemptive
 older transaction may wait for younger one to release
data item. Younger transactions never wait for older
ones; they are rolled back instead.
 a transaction may die several times before acquiring
needed data item
 wound-wait scheme — preemptive
 older transaction wounds (forces rollback) of younge
transaction instead of waiting for it. Younger
transactions may wait for older ones.
12/9/2009 10
 may be fewer rollbacks than wait-die scheme.
 Deadlock prevention (Cont.)

 Both in wait-die and in wound-wait schemes, a

rolled back transactions is restarted with its
original timestamp. Older transactions thus
have precedence over newer ones, and
starvation is hence avoided.
 Timeout-Based Schemes :
 a transaction waits for a lock only for a
specified amount of time. After that, the
wait times out and the transaction is rolled
back.
 thus deadlocks are not possible

 simple to implement; but starvation is

12/9/2009 11
possible. Also difficult to determine good
value of the timeout interval
 Deadlock Detection
 Deadlocks can be described as a wait-for graph, which
consists of a pair G = (V,E),
 V is a set of vertices (all the transactions in the
system)
 E is a set of edges; each element is an ordered pair Ti
→Tj.
 If Ti → Tj is in E, then there is a directed edge from Ti to
Tj, implying that Ti is waiting for Tj to release a data item.
 When Ti requests a data item currently being held by Tj,
then the edge Ti Tj is inserted in the wait-for graph. This
edge is removed only when Tj is no longer holding a data
item needed by Ti.
 The system is in a deadlock state if and only if the wait-
for graph has a cycle. Must invoke a deadlock-detection
algorithm periodically to look for cycles.
12/9/2009 12
 Deadlock Detection (Cont.)

Wait-for graph without a cycle Wait-for graph with a cycle

12/9/2009 13
 Deadlock Recovery
 When deadlock is detected :
 Some transaction will have to rolled back (made a
victim) to break deadlock. Select that transaction as
victim that will incur minimum cost.
 Rollback -- determine how far to roll back transaction

 Total rollback: Abort the transaction and then

restart it.
 More effective to roll back transaction only as far
as necessary to break deadlock.
 Starvation happens if same transaction is always
chosen as victim. Include the number of rollbacks in
the cost factor to avoid starvation

12/9/2009 14
12/9/2009 15