Chapter 4

Concurrency Control Techniques

 Outline
• Introduction
• Why concurrency control ?
• Granularity of data items
• Concurrency control techniques
– Locking techniques
– Timestamp ordering techniques
• Using locks for concurrency control in indexes
• Other concurrency control issues
• Summary
 Introduction
Based on the number of users DBMSs can be
classified as
– Single-user systems
– Multi-user systems
 Concurrency
Concurrency is the ability of the database
management system to process more than one
transaction at a time.
 Interleaved concurrency

The figure shows two programs A and B executing concurrently in an

interleaved fashion.
simultaneous concurrency
 Concurrency control
Concurrency control is the activity of
coordinating concurrent accesses to a database
in a multi-user database management system
(DBMS).
 Uncontrolled concurrency
Two transactions T1 and
T2 submitted by any two
different users may be
executed concurrently and
may access and update
the same database items
(e.g. X)..
 Cont’d
If this concurrent execution is uncontrolled, it
may lead to problems such as
1. The lost update problem
2. The temporary update (dirty read) problem
3. Incorrect summary problem
4. Serializability Theory
Lost Update Problem
Cont’d
 Cont’d

Assume x=80 ,N=5 and M=4

 Uncommitted dependency (or dirty
read / temporary update)
time T1 T2
read_item(X);
X:=X - N;
write_item(X);
read_item(X);
X:=X+M;
write_item(X);
read_item(Y);
T1 fails and aborts
Cont’d
Cont’d
Uncommitted dependency (or dirty
read / temporary update)
Cont’d
Cont’d
Incorrect Summary/inconsistent
Analysis
Cont’d
 Other problems
• unrepeatable read
• Phantom record
 Why concurrency control ?
Why concurrency control is needed?
– 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.
 What Can Go Wrong?
• System may crash before data is written back to disk
= Problem of atomicity
• Some transaction is modifying shared data while
another transaction is ongoing (or vice versa)
= Problem of serialization and isolation
• System may not be able to obtain one or more of the
data items
• System may not be able to write one or more of the
data items
= Problems of atomicity
• DBMS has a Concurrency Control sub sytem to assure
database remains in consistent state despite concurrent
execution of transactions
 Why transaction fail
• There are a variety of causes of transaction
failure. These may include:
– Concurrency control enforcement
– Local error detected by the transaction
– A transaction or system error
– User interruption of the transaction during its
execution
– System software errors
– Crashes due to hardware malfunction
– Disk malfunctions
– Natural physical disasters and catastrophes
 Concurrency Control Techniques
Categories of concurrency techniques
1.Locking techniques
2.Timestamp ordering techniques
3.Multi-version concurrency control techniques
4.Optimistic concurrency control techniques
5.Advanced concurrency control techniques
 Concurrency Control Using Locks
• 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
– Multiple-mode locks:
• Lock table managed by lock manager subsystem of DBMS
 Binary locks
Binary locks
– Locked/unlocked
– Enforces mutual exclusion
Lock and Unlock Operations for Binary
Locks

Lock and unlock operations for binary locks

 Cont’d
• When the binary locking scheme is used, every
transaction must obey the following rules:
– A transaction T must issue the operation lock(X)
before any read_item(X) or write_item(X) operations
are performed in T.
– A transaction T must issue the operation unlock(X)
after all read_item(X) and write_item(X) operations
are completed in T.
– A transaction T will not issue a lock(X) operation if it
already holds the lock on item X.
– A transaction T will not issue an unlock(X) operation
unless it already holds the lock on item X.
 Cont’d
• These rules can be enforced by the lock
manager module of the DBMS.
• At most one transaction can hold the lock on a
particular item. Thus no two transactions can
access the same item concurrently.
• simple but are also too restrictive for
database concurrency control purposes and so
are not used much.
 Multiple-mode locks
Each data item can be in one of three
lock states
–Read lock or shared lock
–Write lock or exclusive lock
–Unlock
lock compatibility table
Locking and unlocking
operations for two-mode
(read/write, or
shared/exclusive) locks
 Cont’d
• When we use the shared/exclusive locking scheme, the system
must enforce the following rules:
– A transaction T must issue the operation read_lock(X) or write_lock(X)
before any read_item(X) operation is performed in T.
– A transaction T must issue the operation write_lock(X) before any
write_item(X) operation is performed in T.
– A transaction T must issue the operation unlock(X) after all
read_item(X) and write_item(X) operations are completed in T.
– A transaction T will not issue a read_lock(X) operation if it already
holds a read (shared) lock or a write (exclusive) lock on item X. This
rule may be relaxed for downgrading of locks, as we discuss shortly.
– A transaction T will not issue a write_lock(X) operation if it already
holds a read (shared) lock or write (exclusive) lock on item X. This rule
may also be relaxed for upgrading of locks, as we discuss shortly.
– A transaction T will not issue an unlock(X) operation unless it already
holds a read (shared) lock or a write (exclusive) lock on item X.
 Conversion of Locks
• 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
• Issue a read_lock operation then a write_lock operation
• Convert read_lock to write_lock
– Downgrade
• Issue a read_lock operation then a write_lock operation
• Convert write_lock to read_lock
 Cont’d
• Using binary locks or read/write locks in
transactions, does not guarantee
serializability of schedules on its own.
Example
 Cont’d
Let’s run T1 and T2 in interleaved fashion

unlocked too early!

 Two-Phase Locking (2PL) Protocol
• Transaction is said to follow the two-phase-locking protocol
if all locking operations (read_lock, write_lock ) precede
the first unlock operation in the transaction .
• Such a transaction can be divided into two phases:
– Growing Phase:
• can acquire a lock-S and lock-X on item
• can convert a lock-S to a lock-X (upgrade)
• Non can be realesed
– Shrinking Phase:
• can release a lock-S and lock-X
• can convert a lock-X (read_lock operation ) to a lock-S (downgrade)
• no new locks can be acquired
• This protocol ensures serializability
 2PL Example

Transactions T1 and T2 do not follow the two-phase locking protocol

 2PL Example

• If we enforce 2PL, the transactions can be rewritten as T1’ and T2’

• Both T1’ and T2’ follow the 2PL protocol
• Any schedule including T1’ and T2’ is guaranteed to be serializable
• Limits the amount of concurrency
 Cont’d
• If every transaction in a schedule follows the
basic 2PL, the schedule is guaranteed to be
serialisable.
• Variants of 2PL
– Basic
– Conservative
– Strict
– Rigorous
 Cont’d
1. Basic 2PL
All lock operations before the first unlock operation
2. Conservative 2PL or static 2PL
Lock all the items it accesses before the transaction begins
execution.
• Deadlock free protocol
• Read-set and write-set of the transaction should be
known
3. Strict 2PL
– a transaction must hold all its exclusive locks till it
commits/aborts.
• Ensures recoverability and avoids cascading roll-backs
• Strict 2PL guarantees strict schedules
 Cont’d
• Rigorous 2PL
– a transaction must hold all locks till commit/abort.
• Transactions can be serialized in the order in which
they commit.
• Most databases implement rigorous two-
phase locking, but refer to it as simply two-
phase locking
Dealing with Deadlocks and Starvation
in 2PL
• 2PL can produce deadlocks
• Deadlock 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.
Cont’d
 Cont’d
• 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
 Wait-die or wound-wait deadlock
prevention protocol
• Timestamp --- a unique identifier created by
the DBMS to identify a transaction.
• The time stamps are ordered based on the
order in which transactions are started;
hence, if transaction T1 starts before
transaction T2, then TS(T1) < TS(T2).
• Two schemes that use transaction timestamp
to prevent deadlock are wait-die and wound-
wait.
 Cont’d
• 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 from held by an older transaction is aborted
and restarted with the same timestamp
– Wound-wait
A younger transaction is allowed to wait on an older
transaction whereas an older transaction requesting
an item from held by a younger transaction preempts
the younger transaction by aborting it.
 Cont’d
wait-die protocol

wound-die protocol
 Cont’d
• The problem with these two schemes is that
they cause some transactions to be aborted
and restarted even though those transactions
may never actually cause a deadlock.
• Another problem can occur with wait-die,
where the transaction Ti may be aborted and
restarted several times in a row because an
older transaction Tj continues to hold the data
item that Ti needs.
 Cont’d
• Two schemes that prevent deadlock and do
not require timestamps
– No waiting
Abort immediately and restart after a certain time
delay
– Cautious waiting
– If 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
• Deadlock detection and timeouts
– Construct and maintain a wait-for graph
• Victim selection
– Timeouts
• Starvation
A transaction cannot proceed for an infinite
period of time while other transactions in the
system continue normally
– Unfair waiting scheme
– Victim selection

ICS 424 - 01 (072) Concurrency Control Techniques 53

 Deadlock detection
• Construct and maintain a wait-for graph
 Concurrency Control Based on
Timestamp Ordering
• Timestamp
– Unique identifier assigned by the DBMS to identify a
transaction
– Assigned in the order submitted
– Transaction start time
• A schedule in which the transactions participate is then
serialisable, and the equivalent serial schedule has the
transactions in order of their timestamp value. This is
called timestamp ordering (TO).
• Concurrency control techniques based on timestamps
do not use locks
– Deadlocks cannot occur
 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
 Cont’d
• Timestamp ordering (TO)
– Allows interleaving of transaction operations.
– Must ensure timestamp order is followed for each pair
of conflicting operations.
• Each database item assigned two timestamp
values
– read_TS(X)
• The largest timestamp among all the timestamps of
transactions that have successfully read item X
– write_TS(X)
• The largest timestamp among all the timestamps of
transactions that have successfully written item X
 Cont’d
• Timestamp Ordering (TO) algorithms
– Basic timestamp ordering
– Strict timestamp ordering
– Thomas’s write rule
 Concurrency Control Based
on Timestamp Ordering (cont’d.)
• Basic TO algorithm
– If conflicting operations detected, later operation
rejected by aborting transaction that issued it
– Schedules produced guaranteed to be conflict
serializable
– Starvation may occur
• Strict TO algorithm
– Ensures schedules are both strict and conflict
serializable
 Concurrency Control Based on Timestamp Ordering (Cont.)
• Basic timestamp ordering algorithm
Order transactions based on their timestamps
1. T issues a write(X)
1.If read-TS(X) > TS(T) or if write-TS(X) > TS(T) the 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.)

• 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 both strict
(for easy recoverability) and (conflict) serializable
 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 for write_item(X) operation
 Concurrency Control Based on Timestamp Ordering (Cont.)
• 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. Notice that any
conflict arising from this situation would be detected by case (1).]
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
 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 technique based on
timestamp ordering
– Two timestamps associated with each version are kept
• read_TS(Xi): this is the largest of all the timestamps of
transactions that have successfully read version Xi.
• write_TS(Xi): this is the timestamp of the transaction that
wrote the value of version Xi. Whenever a transaction T is
allowed to execute a write_item(X) operation, a new version
of item X, Xk+1, is created, with both the write_TS(Xk+1) and
the read_TS(Xk+1) set to TS(T).
• Correspondingly, when a transaction T is allowed to read the
value of version Xi, the value of read_TS(Xi) is set to the
largest of read_TS(Xi) and TS(T).
 Cont’d
• To ensure serialisability, we use the following two rules
to control the reading and writing of data items:
– If transaction T issues a write_item(X) operation, and
version i of X has the highest write_TS(Xi) of all versions of
X which is also less than or equal to TS(T), and TS(T) <
read_TS(Xi), then abort and roll back transaction T;
otherwise, create a new version Xj of X with read_TS(Xj) =
write_TS(Xj) = TS(T).
– If transaction T issues a read_item(X) operation, and
version i of X has the highest write_TS(Xi) of all versions of
X which is also less than or equal to TS(T), then return the
value of Xi to transaction T, and set the value of
read_TS(Xj) to the largest of TS(T) and the current
read_TS(Xj).
Multiversion technique based on two-
phase locking
• there are three locking modes for an item:
– Read
– Write
– certify.
• Hence, the state of an item X can be one of ‘read
locked’, ‘write locked’, ‘certify locked’ and ‘unlocked’.
• allow other transactions T’ to read an item X while a
single transaction T holds a write lock X.
• avoids cascading aborts, since transactions are only
allowed to read the version X that was written by
committed transaction. However, deadlock may occur.
 Cont’d

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
 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
• Transaction committed or aborted based on result
 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)
 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
• Best item size depends on transaction type
Multiple Granularity Level Locking
• Lock can be requested at any level

Figure 21.7 A granularity hierarchy for illustrating multiple granularity level locking
 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
 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
 Reference
• Chapter 21 Concurrency Control Techniques
from Fundamentals of database system 7th
edition
• Chapter 18 Concurrency Control from
Database System Concepts 7th Edition