Granularity of Locks and Degrees of
Consistency in a Shared Data Base
John LaFontaine
Haixuan Sun
Agenda

Background

Overview of locking modes

Rules for acquiring locks

Dynamic lock graphs
Agenda

Background

Overview of locking modes

Rules for acquiring locks

Dynamic lock graphs
Background



Problem: What is the appropriate granularity of
lockable objects in a data base?
Small lockable objects = Increased overhead,
Increased concurrency
Larger = lower overhead, lower concurrency
Granularity of Locks


Intuitively, locking only the exact record being
examined allows for maximum concurrency
However, if a lot of “lockable objects” need to be
examined, there is a lot of overhead



Takes time to set/reset locks each time you need to look
at a record
There is a non-zero storage overhead for representing a
lock in memory
Solution: Allow for multiple granularities of locking
in the same system
Agenda

Background

Overview of locking modes

Rules for acquiring locks

Dynamic lock graphs
Hierarchical Locks




Data Base → Area → File → Table → Record
Each node has a unique parent and nodes at all
levels can be locked
Two types of lock modes

Exclusive (X)

Shared (S)
Explicitly locking a node in one of these two modes
implicitly locks all descendants in the same mode
Table 1
AID
LOC
BAL
1
NY
1500
2
CHI
15000
3
NY
800
4
BOS
2000
5
NY
4000
6
NY
14500
Table 2
AID
DATE
AMT
1
9/26/2011
500
3
10/1/2011
-300
1
10/2/2011
1000
2
10/6/2011
-200
6
10/6/2011
-50
4
10/8/2011
800
Table 1
T1 - S
AID
LOC
BAL
1
NY
1500
2
CHI
15000
3
NY
800
4
BOS
2000
5
NY
4000
6
NY
14500
Table 2
AID
DATE
AMT
1
9/26/2011
500
3
10/1/2011
-300
1
10/2/2011
1000
2
10/6/2011
-200
6
10/6/2011
-50
4
10/8/2011
800
Table 1
T1 - S
T2 - X
AID
LOC
BAL
1
NY
1500
2
CHI
15000
3
NY
800
4
BOS
2000
5
NY
4000
6
NY
14500
Table 2
AID
DATE
AMT
1
9/26/2011
500
3
10/1/2011
-300
1
10/2/2011
1000
2
10/6/2011
-200
6
10/6/2011
-50
4
10/8/2011
800
Intention Modes



Intention mode (I) used to “tag” all ancestors of a
locked node

Intention share mode (IS)

Intention exclusive mode (IX)
Nodes locked in IS mode can be later locked in S
mode, but nodes locked in IX mode cannot
Distinguishing between IS and IX is critical in
enabling concurrency
AID
1
2
3
4
5
6
LOC
NY
CHI
NY
BOS
NY
NY
BAL
1500
15000
800
2000
4000
14500
AID
1
2
3
4
5
6
LOC
NY
CHI
NY
BOS
NY
NY
BAL
1500
15000
800
2000
4000
14500
Result: Poor Concurrency
AID
1
2
3
4
5
6
LOC
NY
CHI
NY
BOS
NY
NY
BAL
1500
15000
800
2000
4000
14500
Share and Intention Exclusive Mode



Abbreviated SIX mode
Has properties of both a shared lock and an intention
exclusive lock
Common case in databases is to scan a sub tree and
modify a small percentage


Avoids high overhead of individually locking each
record examined
Also avoids low concurrency of claiming an exclusive
lock on the entire sub tree being scanned
Mode Summary




NL – no locks held
IS – allows requestor to lock decendants in S or IS
mode, does no actual locking
IX – allows requestor to lock decenants in X, S, IX,
IS, SIX mode, does no actual locking
S – grants shared access to the node and all
decendants of the node without requesting any
further locks
Mode Summary (cont.)


SIX – gives explicit shared access to the requested
node and all decendants, also allows the requestor to
further lock a decendant node in X, SIX, or IX mode
X – gives explicit exclusive access to the requested
node and all decendant nodes
Compatibility Summary
Locking Mode Ordering

The features of the locking modes imply an ordering



The order of IX and S is not defined as they cannot be
compared
X > SIX > S ~ IX > IS > NL
“Higher” locking modes have all the features of the
lower modes
Agenda

Background

Overview of locking modes

Rules for acquiring locks

Dynamic lock graphs
Requesting Locks in a Tree

In general, locks must be acquired root to leaf and
released leaf to root
a) Before requesting IS or S lock on a node, all ancestors
nodes must be held in IS or IX mode
b)Before requesting X, SIX, or IX lock on a node, all
ancestor nodes must be held in IX or SIX mode
c) Locks should be released in leaf to root order (or in any
order when the transaction is over)
Directed Acyclic Graphs


The tree locking hierarchy can be generalized to all
directed acyclic graphs (DAG)
To lock a node in DAG, all parents (may be
multiple) must be locked in the appropriate mode


A node is implicitly locked in S mode if ANY of the
parents are explicitly or implicitly locked in S, SIX, or X
mode
A node is implicitly locked in X mode if ALL of its
parents are locked in X mode
Requesting Locks in a DAG
a)Before requesting an S or IS lock on a node, one
should request at least one parent in IS mode
b)Before requesting IX, SIX, or X mode access to a
node, one should request all parents in IX (or
greater) mode
c)When releasing locks, one should never hold a lower
lock having released its ancestors (or it should
release all locks when the transaction is complete)
Agenda

Background

Overview of locking modes

Rules for acquiring locks

Dynamic lock graphs
Dynamic Lock Graph



So far we have assumed a static database
This is not useful, because if the database were static,
locks would be unnecessary
It is often convenient to lock one particular value of
an indexed attribute


Index Interval locks can be used to do this
Assumes that the indexed fields are stored separately
from the unindexed fields

Can read the indexed values directly (without touching the
actual record)
AID
BAL
AID
LOC
1
1500
4
BOS
2
15000
2
CHI
3
800
1
NY
4
2000
3
NY
5
4000
5
NY
6
14500
6
NY
Index Value Intervals



Normal Locking protocol for DAG is extended
When a indexed field is changed, it must “leave” the
index value interval it was in and “join” a new one
Before moving a node, the node must be locked in X
mode in both its old and new position on the lock
graph

Example: To move an account from the NY branch to the BOS
branch, both the NY and BOS index value intervals would need to
be locked
Outline
• Informal definition of consistency degrees with respect to dirty
data in transaction
• Lock protocol definition of consistency degrees
• Definition of schedule consistency degrees
• Assertion of consistency wrt to dependency
• Transaction backup and system recovery
Outline
• Informal definition of consistency degrees with respect to dirty
data in transaction
• Lock protocol definition of consistency degrees
• Definition of schedule consistency degrees
• Assertion of consistency wrt to dependency
• Transaction backup and system recovery
Consistency and Transactions
• The data base is said to be consistent if it satisfies all its
assertions.
• Transactions preserve consistency.
• Transactions are units of' consistency & recovery.
• An output of a transaction is committed when the transaction
abdicates the right to undo the write.
• Outputs are said to be uncommitted or dirty if they are not yet
committed by the writer.
• Concurrent execution raises the problem that reading or writing
other transactions’ dirty data may yield inconsistent data.
Definition of Consistency wrt Dirty Data
Degree 3 consistency:
Transaction T sees degree 3 consistency if:
a. T does not overwrite dirty data of other transactions.
b. T does not commit any writes until it completes all its writes ( ie.
until the end of transaction (EOT)).
c. T does not read dirty data from other transactions.
d. Other transactions do not dirty any data read by T before T
completes.
Degree 2 consistency:
Transaction T sees degree 2 consistency if:
a. T does not overwrite dirty data of other transactions.
b. T does not commit any writes until the end of transaction.
c. T does not read dirty data from other transactions.
Definition of Consistency wrt Dirty Data
Degree 1 consistency:
Transaction T sees degree 1 consistency if:
a. T does not overwrite dirty data of other transactions.
b. T does not commit any writes until the end of transaction.
Degree 0 consistency:
Transaction T sees degree 0 consistency if:
a. T does not overwrite dirty data of other transactions.
 Note that if a transaction sees a high degree of consistency then it also
sees all the lower degrees.
Recoverability concerning Degrees of
Consistency
• Recoverable transactions can be undone without affecting
other transaction, unrecoverable transactions cannot.
• Degree 0 consistent transactions are unrecoverable, they
commit outputs before the end of transaction.
• Degree 1, 2 &3 consistent is recoverable, they do not
commit any writes until the end of transaction.
Isolation concerning Degrees of Consistency
• Degree 2 consistent transaction isolates itself from the
uncommitted data from other transactions (which can be
updated or undone later).
• Degree 3 consistent transaction isolates itself from dirty
dirty relationship among entities, other transactions do not
dirty any data read by it.
• Degree 3 completely guarantees consistency with regards to
concurrency.
Outline
• Informal definition of consistency degrees with respect to dirty
data in transaction
• Lock protocol definition of consistency degrees
• Definition of schedule consistency degrees
• Assertion of consistency wrt to dependency
• Transaction backup and system recovery
Types of Lock
• Share mode locks allow multiple readers of the same entity.
• Exclusive mode locks reserve exclusive access to an entity.
• Short duration locks are held for the duration of a single action.
• Long duration locks are held to the end of the transaction.
Lock Protocol Definition of Consistency
Degree 3 consistency:
Transaction T sees degree 3 consistency if:
a. T sets a long exclusive lock on any data it dirties.
b. T sets a long share lock on any data it reads.
Degree 2 consistency:
Transaction T sees degree 2 consistency if:
a. T sets a long exclusive lock on any data it dirties.
b. T sets a (possibly short) share lock on any data it reads.
Lock Protocol Definition of Consistency
Degree 1 consistency:
Transaction T sees degree 1 consistency if:
a. T sets a long exclusive lock on any data it dirties.
Degree 0 consistency:
Transaction T sees degree 0 consistency if:
a. T sets a (possibly short) exclusive lock on any data it
dirties.
Well Formed and Two Phase Transaction
• A transaction is well formed with respect to writes (reads) if it
always locks an entity in exclusive (shared or exclusive) mode
before writing (reading) it.
• The transaction is well formed if it is well formed with respect
to reads and writes.
• A transaction is two phase (with respect to reads or updates) if
it does not (share or exclusive) lock an entity after unlocking
some entity.
Definition wrt Well Formed and Two Phase
Degree 3 consistency:
Transaction T sees degree 3 consistency if:
a. T is well formed.
b. T is two phase.
Degree 2 consistency:
Transaction T sees degree 2 consistency if:
a. T is well formed.
b. T is two phase with respect to writes.
Definition wrt Well formed and Two Phase
Degree 1 consistency:
Transaction T sees degree 1 consistency if:
a. T is well formed with respect to writes.
b. T is two phase with respect to writes.
Degree 0 consistency:
Transaction T sees degree 0 consistency if:
a. T is well formed with respect to writes.
Outline
• Informal definition of consistency degrees with respect to dirty
data in transaction
• Lock protocol definition of consistency degrees
• Definition of schedule consistency degrees
• Assertion of consistency wrt to dependency
• Transaction backup and system recovery
Actions and Transaction
• Types of Actions:
– begin, end
– share lock, exclusive lock, unlock
– read, write
 An end action is presumed to unlock any lock.
• A transaction is any sequence of actions beginning with a begin
action and ending with an end action and not containing other
begin or end actions.
Definition of Schedule
• Any sequence preserving merging of the actions of a set of
transactions into a single sequence is called a schedule for the
set of transactions.
• A schedule is legal only if it does not schedule a lock action on
an entity for one transaction when that entity is already locked
by some other transaction in a conflicting mode.
Consistency Degrees of Schedules
• A transaction runs at degree 0 (1,2, or 3) consistency
in schedule S if if T sees degree 0 (1, 2 or 3)
consistency in S.
• If all transactions run at degree 0 (1, 2 or 3)
consistency in schedule S then S is said to be a degree
0 (1,2 or 3) consistent schedule.
Assertions
Assertion 1:
a. If each transaction observes the degree 0 (1, 2 or 3) lock
protocol then any legal schedule is degree 0 (1, 2 or 3)
consistent (ie , each transaction sees degree 0 (1, 2 or 3)
consistency).
b. Unless transaction T observes the degree 1 (2 or 3) lock
protocol then it is possible to define another transaction T’
which does observe the degree 1 (2 o r 3) lock protocol
such that T and T’ have a legal schedule S but T does not
run at degree 1 (2 or 3) consistency in S.
Assertions
Assertion 2:
If each transaction in a set of transactions at least observes the
degree 3 lock protocol and if transaction T observes the degree
1 (2 or 3) lock protocol then T runs at degree 1 (2 or 3)
consistency in any legal schedule for the set of transactions.
Outline
• Informal definition of consistency degrees with respect to dirty
data in transaction
• Lock protocol definition of consistency degrees
• Definition of schedule consistency degrees
• Assertion of consistency wrt to dependency
• Transaction backup and system recovery
Dependencies among Transactions
Dependency relations:
(Suppose transaction T performs action a on entity e, transaction T’ performs action a’ on e
later, T’!= T)
• T<<<T’
1. if a is a write action and a' is a write action
2. or a is a write action and a' is a read action
3. or a is a read action and a' is a write action
• T<<T’
1. if a is a write action and a' is a write action
2. or a is a write action and a' is a read action
• T<T’
1. if a is a write action and a' is a write action
BEFORE and AFTER Set
• BEFORE1(T) = {T||T’<*T}
AFTER1(T) = {T||T <* T’}.
(let <* be the transitive closure of <)
•Analogously BEFORE2, AFTER2, BEFORE3 and AFTER3.
Assertion wrt Dependency
A schedule is degree 1 (2 or 3) consistent if and only if the
relation <* (<<* or <<<* ) is a partial order.
Example
T1
T1
T1
T2
T2
T2
T2
T2
T2
T1
T1
T1
Lock
Read
Unlock
Lock
Write
Lock
Write
Unlock
Unlock
Lock
Write
Unlock
A
A
A
A
A
B
B
A
B
B
B
B
Example
T1
T1
T1
T2
T2
T2
T2
T2
T2
T1
T1
T1
T2<T1, T2<<T1, T2<<<T1
Lock
Read
Unlock
Lock
Write
Lock
Write
Unlock
Unlock
Lock
Write
Unlock
A
A
A
A
A
B
B
A
B
B
B
B
Example
T1
T1
T1
T2
T2
T2
T2
T2
T2
T1
T1
T1
T1<<<T2
Lock
Read
Unlock
Lock
Write
Lock
Write
Unlock
Unlock
Lock
Write
Unlock
A
A
A
A
A
B
B
A
B
B
B
B
Example
T1
T1
T1
T2
T2
T2
T2
T2
T2
T1
T1
T1
T2<<<T1 & T1<<<T2

Lock
Read
Unlock
Lock
Write
Lock
Write
Unlock
Unlock
Lock
Write
Unlock
A
A
A
A
A
B
B
A
B
B
B
B
<<<* is not partial order
Example
T1
T1
T1
T2
T2
T2
T2
T2
T2
T1
T1
T1
Lock
Read
Unlock
Lock
Write
Lock
Write
Unlock
Unlock
Lock
Write
Unlock
A
A
A
A
A
B
B
A
B
B
B
B
T2<<<T1 & T1<<<T2

<<<* is not partial order
The schedule is degree 2 consistent but not degree 3 consistent
Example
T1
T1
T1
T2
T2
T2
T2
T2
T2
T1
T1
T1
Lock
Read
Unlock
Lock
Write
Lock
Write
Unlock
Unlock
Lock
Write
Unlock
A
A
A
A
A
B
B
A
B
B
B
B
T2<<<T1 & T1<<<T2
<<<* is not partial order
The schedule is degree 2 consistent but not degree 3 consistent
T1 runs at degree 2 consistency, T2 runs at degree 3 consistency.
Example
T1
T1
T2
T2
T2
T2
T1
T1
T1
T1
T2<T1, T2<<T1, T2<<<T1
Lock
write
read
Lock
Write
Unlock
Lock
Write
Unlock
Unlock
A
A
A
B
B
B
B
B
B
A
Example
T1
T1
T2
T2
T2
T2
T1
T1
T1
T1
T1<<T2, T1<<<T2
Lock
write
read
Lock
Write
Unlock
Lock
Write
Unlock
Unlock
A
A
A
B
B
B
B
B
B
A
Example
T1
T1
T2
T2
T2
T2
T1
T1
T1
T1
Lock
write
read
Lock
Write
Unlock
Lock
Write
Unlock
Unlock
A
A
A
B
B
B
B
B
B
A
T2<T1, T2<<T1, T2<<<T1, T1<<T2, T1<<<T2
The schedule is degree 1 consistent
Example
T1
T1
T2
T2
T2
T2
T1
T1
T1
T1
Lock
write
read
Lock
Write
Unlock
Lock
Write
Unlock
Unlock
A
A
A
B
B
B
B
B
B
A
T2<T1, T2<<T1, T2<<<T1, T1<<T2, T1<<<T2
The schedule is degree 1 consistent
T1 runs degree 3 consistent, T2 runs degree 1 consistent.
Outline
• Informal definition of consistency degrees with respect to dirty
data in transaction
• Lock protocol definition of consistency degrees
• Definition of schedule consistency degrees
• Assertion of consistency wrt to dependency
• Transaction backup and system recovery
Transaction Backup and System Recovery
• Given any current state and a time ordered log of the updates of
transactions, one can return to a consistent state by un-doing
any incomplete transactions.
• Given a checkpoint and a log which records old and new values,
one can return to a consistent state by undoing all uncommitted
updates made before checkpoint; and by redoing all updates
made in the log.
Transaction Backup and System Recovery
• If the schedule (log) is degree 0 consistent then the actions can
be re-done LOG order (skipping uncommitted updates)
• If the schedule (log) is degree 1 consistent then the actions can
be sorted by transaction in <* order and recovery performed
with the sorted log.
Summary
Summary