concurrency control techniques chapter 18 concurrency control techniques 1
TRANSCRIPT
CONCURRENCY CONTROL CONCURRENCY CONTROL TECHNIQUESTECHNIQUES
CHAPTER 18CHAPTER 18
Concurrency Control Techniques
1
Outline
Concurrency Control Techniques
2
Granularity of data items Concurrency control techniques
1. Locking techniques 2. Timestamp ordering techniques
Concurrency Control Techniques
Concurrency Control Techniques
3
Categories of concurrency techniques1. Locking techniques 2. Timestamp ordering techniques 3. Multi-version concurrency control
techniques 4. Optimistic concurrency control techniques 5. Advanced concurrency control techniques
Granularity of Data Items
Concurrency Control Techniques
4
Data item granularitySize or granule of data for concurrency control. It
could be An attribute value A database record A disk block A whole file The whole database
Data item granularity and degree of concurrency Fine granularity --- refers to small item sizes Coarse granularity --- refers to large item sizes Larger the data item size, lower the degree of
concurrency Data item size depends on the types of
transactions
Concurrency Control Using Locks
Concurrency Control Techniques
5
Lock A variable associated with a data item Describes status of the data item with respect to operations that
can be performed on it Types of locks
Binary locks Locked/unlocked Enforces mutual exclusion
Multiple-mode locks: Each data item can be in one of three lock states
1. Read lock or shared lock2. Write lock or exclusive lock3. Unlock
Lock table managed by lock manager subsystem of DBMS
Lock table – records have 3 fields <data item name, LOCK, locking transaction>
Lock and Unlock Operations for Binary Locks
Concurrency Control Techniques
6
Binary Locking Rules
Concurrency Control Techniques
7
Every transaction must obey the following rules:
1. A transaction T must issue the operation lock_item(X) before any read_item(X) or write_item(X) operations are performed in T.
2. A transaction T must issue the operation unlock_item(X) after all read_item(X) and write_item(X) operations are completed in T.
3. A transaction T will not issue a 1ock_i tem(X) operation if it already holds the lock on item X.
4. A transaction T will not issue an unlock_item(X) operation unless it already holds the lock on item X.
Shared/exclusive Locking Rules
Concurrency Control Techniques
8
1. T must issue read_lock(X) or write_lock(X) before any read_item(X) operation is performed in T
2. T must issue write_lock(X) before any write_item(X) operation is performed in T
3. T must issue unlock(X) after all read_item(X) and write_item(X) operations are completed in T
4. T will not issue a read_lock(X) if it already holds a read lock or write lock on X (may be relaxed)
5. T will not issue a write_lock(X) if it already holds a read lock or write lock on X (may be relaxed)
6. T will not issue unlock (X) request unless it holds a read lock or write lock on X
Conversion of Locks
Concurrency Control Techniques
9
A transaction T that holds a lock on item X, under certain conditions, is allowed to convert the lock from one state to another Upgrade
Convert read_lock to write_lock Downgrade
Convert write_lock to read_lock
Using locks does not guarantee serializability of schedules on its own
Two Transactions
Concurrency Control Techniques
10
T1
read_lock(Y);
read_item(Y);
unlock(Y);
write_lock(X);
read_item(X);
X:=X+Y;
write_item(X);
unlock(X);
T2
read_lock(X);
read_item(X);
unlock(X);
write_lock(Y);
read_item(Y);
Y:=X+Y;
write_item(Y);
unlock(Y);
Let’s assume serial schedule S1: T1,T2
Initial values: X=20, Y=30 Result: X=50, Y=80
Locks Alone Don’t Insure Serializability
Concurrency Control Techniques
11
T1read_lock(Y);read_item(Y);unlock(Y);
write_lock(X);read_item(X);X:=X+Y;write_item(X);unlock(X);
T2
read_lock(X);read_item(X);unlock(X);write_lock(Y);read_item(Y);Y:=X+Y;write_item(Y);unlock(Y);
Non-serializable!
Result: X=50, Y=50
unlocked too early!
Let’s run T1 and T2 in interleaved fashion
Schedule S
Two-Phase Locking (2PL) Protocol
Concurrency Control Techniques
12
Transaction is said to follow the two-phase-locking protocol if all locking operations precede the first unlock operation Expanding (growing) phase
New locks can be acquired but none can be released. Upgrading is ok Downgrading is not
Shrinking phase Existing locks can be released but no new locks can be
acquired Downgrading ok Upgrading is not
2PL Example
Concurrency Control Techniques
13
T1’
read_lock(Y);
read_item(Y);
write_lock(X);
unlock(Y);
read_item(X);
X:=X+Y;
write_item(X);
unlock(X);
T2’
read_lock(X);
read_item(X);
write_lock(Y);
unlock(X);
read_item(Y);
Y:=X+Y;
write_item(Y);
unlock(Y);
• Both T1’ and T2’ follow the 2PL protocol
• Any schedule including T1’ and T2’ is guaranteed to be serializable
• Limits the amount of concurrency
• Can produce a deadlock
Locking Techniques for Concurrency Control
Concurrency Control Techniques
14
Quick review of ideas discussed so far Locks and system lock tables
Lock table and lock manager Binary locks --- lock & unlock operations (critical
sections) Shared/exclusive locks --- read-lock, write-lock, and
unlock Conversion of locks
Upgrade the lock Downgrade the lock
Concurrency control subsystem generates read-lock and write-lock requests on behalf of the transactions
Using locks in transactions does not guarantee serializability of schedules on its own
Locking Techniques for Concurrency Control (Cont.)
Concurrency Control Techniques
15 Two-phase locking protocol (2PL)
All lock operations precede the first unlock operation Expanding phase and shrinking phase Upgrading of locks must be done in expanding
phase and downgrading of locks must be done in shrinking phase
If every transaction in a schedule follows 2PL protocol then the schedules is guaranteed to be serializable.
Variants of 2PLBasic, conservative, strict, and rigorous
Locking Techniques for Concurrency Control (Cont.)
Concurrency Control Techniques
16
1. Basic 2PLAll lock operations before the first unlock operation
2. Conservative 2PL or static 2PL Lock all the items it accesses before the transaction begins execution.
1. Deadlock free protocol2. Read-set and write-set of the transaction should be
known
3. Strict 2PL No exclusive lock will be unlocked until the transaction commits or aborts
4. Rigorous 2PL No lock will be unlocked until the transaction commits or aborts
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
17
2PL can cause two problems:1. Deadlocks2. Starvation
Deadlock in 2PLDeadlock occurs when each transaction T in a set of two or more transactions is waiting for some item that is locked by some other transaction T’ in the set.
Example (next slide)
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
18
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
19
Deadlock prevention protocols Conservative 2PL, lock all needed items in
advance Ordering all items in the database
Possible actions if a transaction is involved in a possible deadlock situation Block and wait Abort and restart Preempt and abort another transaction
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
20
Two schemes that prevent deadlock (Timestamp based) Wait-die
An older transaction is allowed to wait on a younger transaction whereas a younger transaction requesting an item held by an older transaction is aborted and restarted later with the same timestamp.
Wound-wait
A younger transaction is allowed to wait on an older transaction whereas an older transaction requesting an item held by a younger transaction preempts the younger transaction by aborting it.
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
21
Two schemes that prevent deadlock and do not require timestamps
No waitingAbort immediately and restart after a certain
time delay Cautious waitingIf a transaction holding the lock is not waiting
for another item to be locked then allow T to wait otherwise abort and restart T
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
22
Deadlock detection and timeoutsThe system checks if a state of deadlock actually exist
Good: if there will be little interference among transactions
If transactions are short and each locks few data items
If the transaction load is light Bad: otherwise
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
23
Deadlock detection and timeouts1. Construct and maintain a wait-for graph
A directed edge from Ti to Tj is created when Ti is waiting to lock an item X that is currently locked by by Tj
If the system detects a deadlock (cycle in the graph), some of the transactions causing the deadlock must be aborted (Victim selection)
Problem: when the system should check for a deadlock?2. Timeouts
If a transaction waits for a period longer than a system-defined timeout period, the system assumes that the transaction maybe deadlocked and aborts it—regardless of whether a deadlock actually exists or not.
Practical ( low overhead + simplicity )
Dealing with Deadlocks and Starvation in 2PL
Concurrency Control Techniques
24
StarvationA transaction cannot proceed for an infinite period of time while other transactions in the system continue normally
Unfair waiting scheme giving priority to some transactions over others.
Sol: FCFS , increase priority as the longer wait Victim selection
Sol: increase priority as aborted multiple times No starvation in wait-die and wound-wait
schemes.
Concurrency Control Based on Timestamp Ordering
Concurrency Control Techniques
25
Timestamp a unique identifier created by the DBMS to identify a transactionTimestamp values are assigned in the order in which the transactions are submitted to the system (can be thought of as the transaction start time)Can be implemented using:
a counter incremented each time its value is assigned to a transaction
the current date/time value of the system clock and ensure that no two timestamp values are generated during the same tick of the clock.
Concurrency Control Based on Timestamp Ordering
Concurrency Control Techniques
26
Timestamp Ordering Algorithm (TO)does not use locks, hence, deadlocks cannot occur.orders the transactions based on their timestamps. A schedule in which the transactions participate is then serializable, and the equivalent serial schedule has the transactions in order of their timestamp values.
In 2PL, a schedule is serializable by being equivalent to some serial schedule allowed by the locking protocols.
In timestamp ordering, however, the schedule is equivalent to the particular serial order corresponding to the order of the transaction timestamps.
The algorithm must ensure that, for each item accessed by conflicting operations in the schedule, the order in which the item is accessed does not violate the serializability order.
Concurrency Control Based on Timestamp Ordering
Concurrency Control Techniques
27
Timestamp Ordering Algorithm (TO) Read-TS(X)
The largest timestamp among all the timestamps of transactions that have successfully read item X
Read-TS(X) = TS(T), where T is the youngest transaction that has read X successfully.
Write-TS(X) The largest timestamp among all the timestamps of
transactions that have successfully written item X Write_TS(X)= TS(T), where T is the youngest
transaction that has written X successfully.TO algorithm variations:
Basic timestamp ordering Strict timestamp ordering Thomas’s write rule
Concurrency Control Techniques
28
Basic timestamp ordering algorithm1.T issues a write(X)
1. If read-TS(X) > TS(T) or if write-TS(X) > TS(T) then abort and rollback T and reject the operation.
2. If condition above does not occur then execute the operation and set write-TS(X) = TS(T)
2.T issues a read(X)1. If write-TS(X) > TS(T) then abort and rollback T and
reject the operation.2. If write-TS(X) TS(T) then execute the operation
and set read-TS(X) = max ( read-TS(X), TS(T) )
The schedules produced by basic TO are guaranteed to be conflict serializable
No deadlocks but cyclic restart are possible (hence starvation)
Concurrency Control Based on Timestamp Ordering (Cont.)
Concurrency Control Based on Timestamp Ordering (Cont.)
Concurrency Control Techniques
29
Strict Timestamp Ordering (strict TO) A transaction T that issues a read-item(X) or
write-item(X) such that TS(T) > write-TS(X) has its read or write operation delayed until the transaction T’ that wrote the value of X (hence TS(T’ ) = write-TS(X)) has committed or aborted.
No deadlocks, since T waits for T’ only if TS(T) > TS(T’)
Strict TO ensures that the schedules are (conflict) serializable
Concurrency Control Techniques
30
Thomas’s write rule It rejects fewer write operations, by modifying the
basic TO checks for the write-item(X) operation as follows: 1. If read-TS(X) > TS(T), then abort and roll back T and
reject the operation. 2. If write-TS(X) > TS(T), then do not execute the write
operation but continue processing. [This is because some transaction with timestamp greater than TS(T)—and hence after T in the timestamp ordering—has already written the value of X. Hence, we must ignore the write_item(X) operation of T because it is already outdated and obsolete.]
3. If neither the condition in part (1) nor the condition in part (2) occurs, then execute the write-item(X) operation of T and set write-TS(X) to TS(T).
Thomas’ write rule does not enforce conflict serializability
Concurrency Control Based on Timestamp Ordering (Cont.)
Summary
Concurrency Control Techniques
31
Granularity of data items Concurrency control techniques
1. Locking techniques 2. Timestamp ordering techniques
Thank you