Fundamental of Database management System

CHAPTER 4
Concurrency Control Techniques

By: Shewakena G.
 Slide Title
1. Locking Techniques for Concurrency Control
2. Concurrency Control Based ON Timestamp Ordering
3. Multi-version Concurrency Control Techniques
4. Validation (Optimistic) Concurrency Control
Techniques
5. Granularity of Data Items and Multiple Granularity
Locking
6. Using Locks for Concurrency Control in Indexes
 Introduction
Concurrency control Techniques
 Concurrency control protocols
 Ensure the non interference or isolation property of concurrently executing
transactions.
 Set of rules to guarantee serializability (refers sequence of actions to correct)
 Two-phase locking protocols
 Lock data items to prevent concurrent access
 Timestamp
 Unique identifier for each transaction
 Multiversion currency control protocols
 Use multiple versions of a data item
 Validation or certification of a transaction called Optimistic
 Concurrency control
Techniques
• Basic Concurrency techniques:
– Locking
– Time stamping
– Optimistic methods
• Locking and Time stamping are conservative approaches.
– Locking all data item before transaction begins.
– Delay transaction in case they conflict with other transaction.
• Optimistic methods are conflict is rare and only check for
conflicts at commit.
 Database Concurrency Control
• Purpose of Concurrency Control
– To enforce Isolation (through mutual exclusion) among conflicting transactions.
– To preserve database consistency through consistency preserving execution of
transactions.
– To resolve read-write and write-write conflicts.
• Example:
– In concurrent execution environment if T1 conflicts with T2 over a data item A.
– Then the existing concurrency control decides if T1 or T2 should get the A and
if the other transaction is rolled-back or waits.
 Concurrency Control Techniques
♦ Locking Permission to Read or T Write.
Variable associated with a data item.
Describing status for possible operations that can be applied
One lock for each item in the database
A transaction must claim a shared(read) or exclusive(write) lock on a data item before read
or write.
Lock prevents another transaction from modifying item or even reading it, in the case of a
write lock.
♦ Binary locks
Two states (values) and have Atomic operation.
 Locked (1)
● Item cannot be accessed
 Unlocked (0)
 4.1Two-Phase Locking Techniques for Concurrency Control
 Two-Phase Locking Techniques
– Locking is an operation which secures
• permission to Read
• permission to Write a data item for a transaction.
– Example:
• Lock (X). Data item X is locked in behalf of the requesting transaction.
– Unlocking is an operation which removes these permissions
from the data item.
– Example:
• Unlock (X): Data item X is made available to all other transactions.
– Lock and Unlock are Atomic operations.
 Database Concurrency Control
 Two-Phase Locking Techniques: Essential components
– Two locks modes:
• (a) shared (read) (b) exclusive (write).
– Shared mode: shared lock (X)
• More than one transaction can apply share lock on X for reading its value.
• but no write lock can be applied on X by any other transaction.
– Exclusive mode: Write lock (X)
• Only one write lock on X can exist at any time and no shared lock can be
applied by any other transaction on X.
– Conflict matrix Read Write
Read

Y N

No Conflict N N
Wr
 4.1Two-Phase Locking Techniques for Concurrency
Control

 Two-Phase Locking Techniques: Essential components

– Lock Manager:
• Managing locks on data items.
– Lock table:
• Lock manager uses it to store the identify of transaction
locking a data item, the data item, lock mode and pointer to
the next data item locked.
• One simple way to implement a lock table is through linked
list.
Transaction ID Data item id lock mode Ptr to next data item
T1 X1 Read Next
 4.1Two-Phase Locking Techniques for Concurrency
Control

Two-Phase Locking Techniques: Essential

components
– Database requires that all transactions should be well-
formed.
– A transaction is well-formed if:
• It must lock the data item before it reads or writes to it.
• It must not lock an already locked data items and it must not
try to unlock a free data item.
Slide 18- 10
 Locking Basic Rules
 If the simple binary locking scheme described here is used, every transaction must obey the following
rules:
– A transaction T must issue the operation lock_item(X) before any read_item(X) or write_item(X)
operations are performed in T.
– A transaction T must issue the operation unlock_item(X) after all read_item(X) and write_item(X)
operations are completed in T.lock_item(X):
– A transaction T will not issue a lock_item(X) operation if it already holds the lock on item X.
– A transaction T will not issue an unlock_item(X) operation unless it already holds the lock on item
X.
– If transaction has shared lock on item, can read but not update item.
– If transaction has exclusive lock on item, can both read and update item.
– Read cannot conflict, more than one transaction can hold shared lock simultaneously on same item.
– Exclusive lock gives transaction exclusive access to only one item at a time.
 These rules can be enforced by the lock manager module of the DBMS. Between the lock_item(X) and
unlock_item(X) operations in transaction T,
 Variations of Two-Phase Locking
Two-phase locking variation:
 Conservative 2PL:
– Prevents deadlock by locking all desired data items before transaction
begins execution.
• Predeclare read-set and write-set
– Deadlock-free protocol
 Basic 2PL:
– Transaction locks data items incrementally.
– This may cause deadlock which is dealt with.
 Strict 2PL:
– A more stricter version of Basic algorithm where unlocking is performed
after a transaction terminates (commits or aborts and rolled-back).
– This is the most commonly used two-phase locking algorithm.
 Variations of Two-Phase Locking con…

Two-phase locking variation:

 Rigorous 2PL
– Transaction does not release any locks until after it
commits or aborts
• Concurrency control subsystem responsible for
generating read_lock and write_lock requests
• Locking generally considered to have high
overhead
 Guaranteeing Serializability by Two-Phase Locking

• If every transaction in a schedule follows the two-

phase locking protocol, schedule guaranteed to be
serializable
• Two-phase locking may limit the amount of concurrency
that can occur in a schedule
• Some serializable schedules will be prohibited by two-
phase locking protocol
 4.1Two-Phase Locking Techniques for Concurrency
Control

Two-Phase Locking Techniques: Essential

components
– The following code performs the read operation:
B: if LOCK (X) = “unlocked” then
begin LOCK (X)  “read-locked”;
no_of_reads (X)  1;
end
else if LOCK (X)  “read-locked” then
no_of_reads (X)  no_of_reads (X) +1
else begin wait (until LOCK (X) = “unlocked” and
the lock manager wakes up the transaction);
 4.1Two-Phase Locking Techniques for Concurrency
Control

 Two-Phase Locking Techniques: Essential components

– The following code performs the write read_lock(x):
B: if LOCK (X) = “unlocked” then
begin
LOCK (X)  “read-locked”;
no_of_reads (X)  1;
end
else if LOCK (X)  “read-locked” then
no_of_reads (X)  no_of_reads (X) +1
else begin
wait (until LOCK (X) = “unlocked” and
the lock manager wakes up the
transaction);
go to B
 4.1Two-Phase Locking Techniques for Concurrency
Control

Two-Phase Locking Techniques: Essential components

The following code performs the Write_lock(x):
B:if LOCK (X)  “unlocked” then
LOCK (X) = “write-locked” ;
Else
Wait(until LOCK(X)=“Unlocked”;
and the lock manager wakes up the transaction);
Goto B
end;
 Two-Phase Locking Techniques for Concurrency
Control
 Two-Phase Locking Techniques: Essential components
• Lock conversion
 Transaction that already holds a lock allowed to convert the lock from one
state to another
– Lock upgrade: existing read lock to write lock
if Ti has a read-lock (X) and Tj has no read-lock (X) (i  j) then
convert read-lock (X) to write-lock (X)
else
force Ti to wait until Tj unlocks X
– Lock downgrade: existing write lock to read lock
Ti has a write-lock (X) (*no transaction can have any lock on X*)
convert write-lock (X) to read-lock (X)
 Guaranteeing Serializability by Two-
Phase Locking
 Two-Phase Locking Techniques: The algorithm
• Two Phases locking protocol:
– Transaction follows 2PL protocol if all locking operation precede first unlock operation
in the transaction.
1) Locking (Growing) Phase:
– A transaction applies locks (read or write) on desired data items one at a time.
– Acquire all locks but can not release any lock.
– Lock conversion upgrades must be done during this phase
2) Unlocking (Shrinking) Phase:
– A transaction unlocks its locked data items one at a time.
– Release lock but cannot acquire any new locks.
– Downgrades must be done during this phase
• Requirement:
– For a transaction these two phases must be mutually exclusively, that is, during locking phase
unlocking phase must not start and during unlocking phase locking phase must not begin.
 Guaranteeing Serializability by Two-
Phase Locking
Two-Phase Locking Techniques: #here The algorithm not follows 2PL
T1 T2 Result
read_lock (Y); read_lock (X); Initial values: X=20; Y=30
read_item (Y); read_item (X); Result of serial execution
unlock (Y); unlock (X); T1 followed by T2
write_lock (X); Write_lock (Y); X=50, Y=80.
read_item (X); read_item (Y); Result of serial execution
X:=X+Y; Y:=X+Y; T2 followed by T1
write_item (X); write_item (Y); X=70, Y=50
unlock (X); unlock (Y);
 Guaranteeing Serializability by Two-
Phase Locking
 Two-Phase Locking Techniques: # Here The algorithm not follows 2PL
T1 T2 Result
read_lock (Y); X=50; Y=50
read_item (Y); Nonserializable because it.
unlock (Y); violated two-phase policy.
read_lock (X);
read_item (X);
Time unlock (X);
write_lock (Y);
read_item (Y);
Y:=X+Y;
write_item (Y);
unlock (Y);
write_lock (X);
read_item (X);
X:=X+Y;
write_item (X);
unlock (X);
 Guaranteeing Serializability by Two-
Phase Locking
 Two-Phase Locking Techniques: The algorithm
T’1 T’2
read_lock (Y); read_lock (X); T1 and T2 follow two-phase
read_item (Y); read_item (X); policy but they are subject to
write_lock (X);Write_lock (Y); deadlock, which must be
unlock (Y); unlock (X); dealt with.
read_item (X); read_item (Y);
X:=X+Y; Y:=X+Y;
write_item (X);write_item (Y);
unlock (X); unlock (Y);
=>If every transaction in the schedule follows the 2PL protocol, the schedule is guaranteed to be
serializable.
Þ Locking can cause two problems:
Þ Deadlock
 Dealing with Deadlock and Starvation
 Deadlock
– Occurs when each transaction T in a set is waiting for some item locked by some
other transaction T’
– Both transactions stuck in a waiting queue

– T’1 and T’2 are in deadlock

 The DBMS must either prevent or detected and recovered such
 Dealing with Deadlock and Starvation (cont’d.)

 Deadlock prevention protocols

– One ways of preventing deadlock is to use a deadlock prevention
protocols such as:
1. Conservative two-phase protocol
 Every transaction locks all items it needs in advance.
 But this is not practical since it limits concurrency
2. Ordering all items in the database
 Transaction that needs several items will lock them in that order.
 This require that the program or the software is aware of the chosen
order of the items, which also not practical
 Dealing with Deadlock and
Starvation (cont’d.)
 Deadlock prevention protocols
3. Protocols based on a timestamp
– Transaction timestamp TS(T), which is unique identifier assigned to each
transaction.
– It is based on the order in which the transaction are started
– If T1 starts before transaction T2, then
• TS(T1)<TS(T2)
• The lower timestamp, the highest the transaction’s priority, that is, the oldest transaction
has the highest priority.
• The older transaction ( which start first ) has the smaller timestamp values
• There are two types of schemes that prevent deadlock based on timestamp these are:
– Wait-die
 Dealing with Deadlock and
Starvation (cont’d.)
 Protocols based on a timestamp
– Suppose that transaction Ti tries to lock an item X but is not able to because X is locked by some
other transaction Tj with a conflicting lock.
– The rules followed by these schemes are:
• Wait-die. (Ti has high priority, it is allowed to wait, otherwise it is aborted.)
– If TS(Ti) < TS(Tj),
then (Ti older than Tj) Ti is allowed to wait;
otherwise (Ti younger than Tj)
abort Ti (Ti dies) and restart it later with the same timestamp.

T1(ts =10): M is locked , K is requested

wait
wait T2 (ts =20): K is locked, Z is requested
wait
T3 (ts =25) : Z is locked, M is requested
 Dealing with Deadlock and Starvation
(cont’d.)

• Wait-die.
– Protocols based on a timestamp
– In wait-die protocol the following will happen
◦ If Ti has higher priority, it is allowed to wait; otherwise it is
aborted.
◦ An older transaction is allowed to wait on a younger
transaction.
◦ A younger transaction requesting an item held by an older
transaction is aborted
 Dealing with Deadlock and Starvation
(cont’d.)
• Wound-wait.
– The opposite of wait-die.
– If Ti has higher priority, aborted Tj, otherwise Ti waits.
– A younger transaction is allowed to wait on an older one.
– An older transaction requesting an item held by younger transaction preempts the
younger transaction by aborting it.
– If TS(Ti)<TS(Tj), then (Ti older than Tj), Abort Tj(Ti wounds Tj) and restart Tj later
with the same timestamp. Otherwise (Ti younger than Tj) Ti is allowed to wait.
T1(ts =25)
wait
wait wait T2 (ts =20)

T3 (ts =10)
 Dealing with Deadlock and Starvation
(cont’d.)
4. No waiting algorithm
– If transaction unable to obtain a lock, immediately aborted and restarted later.
– It restart after a certain time delay without checking whether a deadlock will actually occur or not
• No transaction wait no deadlock
• Make transaction to abort and restart needlessly
5. Cautious waiting algorithm
• Suppose T1 wait item X that is locked by Tj, and if Tj is not locked (waiting for some other
locked item), then Ti is blocked and allowed to wait otherwise abort Ti
– Deadlock-free
– Reduce the number of needless abort and restart
6. Deadlock detection
– System checks to see if a state of deadlock exists
– Wait-for graph
 Dealing with Deadlock and
Starvation (cont’d.)
 Deadlock Detection
– Simple way to detect a state of deadlock is to draw wait-for-graph
– The system construct and maintain a wait-for graph
• G(V, E)
Where: V is nodes describing transaction
E is directed edge
– Ti Tj
Directed edge { Ti is waiting for a data item held by Tj}
• Then the system check if there is a cycle in the wait-for graph
 Dealing with Deadlock and Starvation
(cont’d.)
 Deadlock Detection
– The other method to detect a deadlock is use of timeouts
– The system defined a timeout period
– If a transaction waits for a period longer than a system defined
time out period, the system assume that the transaction may be
deadlock and abort it. (May be even there is no deadlock )
– It is practical because of low overhead and simplicity
 Dealing with Deadlock and
Starvation (cont’d.)
 Victim selection
– Deciding which transaction to abort in case of deadlock
– While it select the transaction to be abort it looks the transaction that
cost minimum to decide that we can analyze with the following
points:
• Length of transaction timestamp – the younger transaction that has big
timestamp will be selected
• Data item used by transaction- Transaction that used less data item used is
selected
• Data item that are need to be locked – a transaction that needs more data item
to lock is selected
• How many transaction to be rolled back – a transaction that cause minimum
 Dealing with Deadlock and Starvation
(cont’d.)

 Starvation
– Occurs if a transaction cannot proceed for an indefinite
period of time while other transactions continue normally
– An algorithm dealing with deadlock prevent select same
transaction victim repeatedly, thus causing it abort and
never finish execution
– This problem can be solved by
• Modifying the time stamp of the starved transaction
• Increasing the priority of the transaction
 4.2 Concurrency Control Based on
Timestamp Ordering

 Timestamp
– Unique identifier assigned by the DBMS to identify a transaction
– Assigned the value that show the order in which the transaction is
submitted
– Transaction start time – TS(T)
– For example – incremental timestamps
• Date/time value of the system
 Concurrency control techniques based on timestamps do not use
locks; hence,
• Deadlocks cannot occur
 Concurrency Control Based on
Timestamp Ordering (cont’d.)
 Generating timestamps
– Counter incremented each time its value is assigned to
a transaction
– Current date/time value of the system clock
• Ensure no two timestamps are generated during the same tick
of the clock
 General approach
– Enforce equivalent serial order on the transactions
based on their timestamps
 Concurrency Control Based on
Timestamp Ordering (cont’d.)
 Timestamp ordering (TO)
– Allows interleaving of transaction operations
– Must ensure timestamp order is followed for each pair of conflicting operations
– In time stamp ordering, the schedule is equivalent to the particular serial order
corresponding to the one of the transaction timestamps
 Each database item assigned two timestamp values
– read_TS(X) – read timestamp of the x , largest timestamp from all
timestamps read X .
read _TS(X)= TS(S) younger transaction
– write_TS(X)- largest write timestamp
write_TS(x)= TS(T) younger transaction
 Concurrency Control Based on
Timestamp Ordering (cont’d.)
 Basic TO algorithm
– Whenever some transaction T tries to issue a read_item(x) or write-
item(x) operation, the basic OT algorithm compare the read_TS(X) and
Write_TS(x) to ensure that the timestamp of the transaction execution of
time is not violated
– If the order of the transaction is violated, then the transaction T is aborted
and resubmitted to the system as new transaction with new timestamp
– If conflicting operations detected, later operation rejected by aborting
transaction that issued it
– Schedules produced guaranteed to be conflict serializable
– Starvation may occur
 Concurrency Control Based on Timestamp Ordering
(cont’d.)

– Basic TO maybe not recoverable (there will be cascading rolled back),

to ensure the recoverability additional protocol must be enforced
– Ensures schedules are both strict and conflict serializable
1. Whenever a transaction T issues a read_item(X) operation, the
following check is performed:
a. If write_TS(X) > TS(T), then abort and roll back T and reject the operation.
This should be done because some younger transaction with timestamp greater than TS(T)—
and hence after T in the timestamp ordering—has already written the value of item X before T
had a chance to read X.

b. If write_TS(X) ≤ TS(T), then execute the read_item(X) operation

of T and set read_TS(X) to the larger of TS(T) and the current
read_TS(X)
 Concurrency Control Based on
Timestamp Ordering (cont’d.)
2. Whenever a transaction T issues a write_item(X) operation, the following check is performed:
a. If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then abort and roll back Tand
reject the operation.
This should be done because some younger trans-action with a timestamp
greater than TS(T)—and hence after T in the timestamp ordering—has already
read or written the value of item Xbefore T had a chance to write X, thus
violating the timestamp ordering.
b. If the condition in part (a) does not occur, then execute the write_item(X) operation
of T and set write_TS(X) to TS(T)
• Basic TO are hence guaranteed to be conflict serializable
• No Deadlock
• Cycle restart(and hence starvation) may occur in transaction is continually aborted and
restarted
 Concurrency Control Based on Timestamp
Ordering (cont’d.)

 Strict Timestamp Ordering (TO).

– A variation of basic TO called strict TO ensures that the
schedules are both strict (for easy recoverability) and (conflict)
serializable.
– In this variation, a transaction T 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.
 Concurrency Control Based on
Timestamp Ordering (cont’d.)
 Thomas’s write rule
– Modification of basic TO algorithm
– Does not enforce conflict serializability
– Rejects fewer write operations by modifying checks
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.
Thus, 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)for write_item(X)
 4.3 Multiversion Concurrency Control
Techniques
 Several versions of an item are kept by a system
 Some read operations that would be rejected in other techniques
can be accepted by reading an older version of the item
– Maintains serializability
 More storage is needed
 Multiversion currency control scheme types
– Based on timestamp ordering
– Based on two-phase locking
– Validation and snapshot isolation techniques
 Multiversion Concurrency Control
Techniques (cont’d.)
• Multiversion technique based on timestamp
ordering
– Two timestamps associated with each version
are kept
• read_TS(Xi)
• write_TS(Xi)
 Multiversion Concurrency Control
Techniques (cont’d.)
– Multiversion two-phase locking using certify locks
• Three locking modes: read, write, and certify

Figure 21.6 Lock compatibility tables (a) Lock compatibility table for read/write locking
scheme (b) Lock compatibility table for read/write/certify locking scheme
 4.4 Validation (Optimistic) Techniques and Snapshot
Isolation Concurrency Control

 Optimistic techniques
– Also called validation or certification techniques
– No checking is done while the transaction is executing
– Updates not applied directly to the database until
finished transaction is validated
• All updates applied to local copies of data items
– Validation phase checks whether any of transaction’s
updates violate serializability
•
 Concurrency Control Based on
Snapshot Isolation
 Transaction sees data items based on committed values of
the items in the database snapshot
– Does not see updates that occur after transaction starts
 Read operations do not require read locks
– Write operations require write locks
 Temporary version store keeps track of older versions of
updated items
 Variation: serializable snapshot isolation (SSI)
 4.5 Granularity of Data Items and
Multiple Granularity Locking

 Size of data items known as granularity

– Fine (small)
– Coarse (large)
 Larger the data item size, lower the degree of concurrency
permitted
– Example: entire disk block locked
 Smaller the data item size, more locks required
– Higher overhead
 Multiple Granularity Level Locking

• Lock can be requested at any level

Figure 21.7 A granularity hierarchy for illustrating multiple granularity level locking
Slide 21- 48
 Multiple Granularity Level Locking
(cont’d.)
 Intention locks are needed
– Transaction indicates along the path from the root to the
desired node, what type of lock (shared or exclusive) it
will require from one of the node’s descendants
 Intention lock types
– Intention-shared (IS)
• Shared locks will be requested on a descendant node
– Intention-exclusive (IX)
• Exclusive locks will be requested
Slide 21- 49
 Multiple Granularity Level Locking
(cont’d.)

• Intention lock types (cont’d.)

– Shared-intension-exclusive (SIX)
• Current node is locked in shared mode but one or more
exclusive locks will be requested on a descendant node

Figure 21.8 Lock compatibility matrix for multiple granularity locking

 Multiple Granularity Level Locking (cont’d.)

Multiple granularity locking (MGL) protocol rules

 4.6 Using Locks for Concurrency Control
in Indexes

 Two-phase locking can be applied to B-tree and B+ -tree

indexes
– Nodes of an index correspond to disk pages
 Holding locks on index pages could cause transaction
blocking
– Other approaches must be used
 Conservative approach
– Lock the root node in exclusive mode and then access the
appropriate child node of the root
 Using Locks for Concurrency Control in
Indexes (cont’d.)
• Optimistic approach
– Request and hold shared locks on nodes leading to the leaf node,
with exclusive lock on the leaf
• B-link tree approach
– Sibling nodes on the same level are linked at every level
– Allows shared locks when requesting a page
– Requires lock be released before accessing the child node
 Other Concurrency Control
Issues
 Insertion
– When new data item is inserted, it cannot be accessed until after
operation is completed
 Deletion operation on the existing data item
– Write lock must be obtained before deletion
 Phantom problem
– Can occur when a new record being inserted satisfies a condition
that a set of records accessed by another transaction must satisfy
– Record causing conflict not recognized by concurrency control
protocol
 Other Concurrency Control
Issues (cont’d.)
 Interactive transactions
– User can input a value of a data item to a transaction T
based on some value written to the screen by transaction
T′, which may not have committed
– Solution approach: postpone output of transactions to the
screen until committed
 Latches
– Locks held for a short duration
– Do not follow usual concurrency control protocol
 Summary

 Concurrency control techniques

– Two-phase locking
– Timestamp-based ordering
– Multiversion protocols
– Snapshot isolation
 Data item granularity
 Locking protocols for indexes
 Phantom problem and interactive
Slide 21- transaction
56 issues
End of Chapter Four
Thank You

57