Post on 12-Feb-2016
description
transcript
Granularity of Locks and Degrees of Consistency in a Shared Data Base
John LaFontaineHaixuan 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
AID LOC BAL1 NY 1500
2 CHI 15000
3 NY 800
4 BOS 2000
5 NY 4000
6 NY 14500
AID DATE AMT1 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
Table 2
AID LOC BAL1 NY 1500
2 CHI 15000
3 NY 800
4 BOS 2000
5 NY 4000
6 NY 14500
AID DATE AMT1 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
Table 2
T1 - S
AID LOC BAL1 NY 1500
2 CHI 15000
3 NY 800
4 BOS 2000
5 NY 4000
6 NY 14500
AID DATE AMT1 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
Table 2
T1 - S
T2 - X
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 LOC BAL1 NY 15002 CHI 150003 NY 8004 BOS 20005 NY 40006 NY 14500
AID LOC BAL1 NY 15002 CHI 150003 NY 8004 BOS 20005 NY 40006 NY 14500
Result: Poor Concurrency
AID LOC BAL1 NY 15002 CHI 150003 NY 8004 BOS 20005 NY 40006 NY 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 roota)Before requesting IS or S lock on a node, all ancestors
nodes must be held in IS or IX modeb)Before requesting X, SIX, or IX lock on a node, all
ancestor nodes must be held in IX or SIX modec)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
1 1500
2 15000
3 800
4 2000
5 4000
6 14500
AID LOC
4 BOS
2 CHI
1 NY
3 NY
5 NY
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 Lock AT1 Read AT1 Unlock AT2 Lock AT2 Write AT2 Lock BT2 Write BT2 Unlock AT2 Unlock BT1 Lock BT1 Write BT1 Unlock B
Example
T1 Lock AT1 Read AT1 Unlock AT2 Lock AT2 Write AT2 Lock BT2 Write BT2 Unlock AT2 Unlock BT1 Lock BT1 Write BT1 Unlock B
T2<T1, T2<<T1, T2<<<T1
Example
T1 Lock AT1 Read AT1 Unlock AT2 Lock AT2 Write AT2 Lock BT2 Write BT2 Unlock AT2 Unlock BT1 Lock BT1 Write BT1 Unlock B
T1<<<T2
Example
T1 Lock AT1 Read AT1 Unlock AT2 Lock AT2 Write AT2 Lock BT2 Write BT2 Unlock AT2 Unlock BT1 Lock BT1 Write BT1 Unlock B
T2<<<T1 & T1<<<T2 <<<* is not partial order
Example
T1 Lock AT1 Read AT1 Unlock AT2 Lock AT2 Write AT2 Lock BT2 Write BT2 Unlock AT2 Unlock BT1 Lock BT1 Write BT1 Unlock B
T2<<<T1 & T1<<<T2 <<<* is not partial order The schedule is degree 2 consistent but not degree 3 consistent
Example
T1 Lock AT1 Read AT1 Unlock AT2 Lock AT2 Write AT2 Lock BT2 Write BT2 Unlock AT2 Unlock BT1 Lock BT1 Write BT1 Unlock B
T2<<<T1 & T1<<<T2 <<<* is not partial order The schedule is degree 2 consistent but not degree 3 consistentT1 runs at degree 2 consistency, T2 runs at degree 3 consistency.
Example
T1 Lock AT1 write AT2 read AT2 Lock BT2 Write BT2 Unlock BT1 Lock BT1 Write BT1 Unlock BT1 Unlock A
T2<T1, T2<<T1, T2<<<T1
Example
T1 Lock AT1 write AT2 read AT2 Lock BT2 Write BT2 Unlock BT1 Lock BT1 Write BT1 Unlock BT1 Unlock A
T1<<T2, T1<<<T2
Example
T1 Lock AT1 write AT2 read AT2 Lock BT2 Write BT2 Unlock BT1 Lock BT1 Write BT1 Unlock BT1 Unlock A
T2<T1, T2<<T1, T2<<<T1, T1<<T2, T1<<<T2 The schedule is degree 1 consistent
Example
T1 Lock AT1 write AT2 read AT2 Lock BT2 Write BT2 Unlock BT1 Lock BT1 Write BT1 Unlock BT1 Unlock 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