Concurrency Control

Locking Protocols : Two phase Locking ,

Timestamp based Locking , Deadlocks
• Need of Concurrency Control Protocol
• To maintain the consistency of shared data access
during concurrent execution.
• Attempting to have maximum possible concurrency
without inconsistency.
 Mechanisms To Control the Concurrency:

•There are two mechanisms by which we can control concurrency

according to our needs.
1. The mechanism in which the user is responsible to write the
consistent concurrent transactions and they are called Lock
Based Protocols.
2. second mechanism is that in which system itself tries to detect
possible inconsistency during concurrent execution and either the
inconsistency recovered or avoided. They are called Time
Stamping Protocols.
 Lock-Based Protocols
• Inconsistency occurs when two transactions
attempt to modify the same data item at the same time.

• A general solution to this problem is that, if one

transaction is accessing a data item then, no other transaction
should be allowed to modify that data item

• Locks are used to implement this solution.

 Lock-Based Protocols
Lock- is a variable associated with each data item
that describes the status of the item with respect
to possible operations that can be applied to it.

There are two types of locks:

•Binary locks
•Shared/Exclusive locks
.......... helps solve concurrency problem.
A. locking
B. transaction monitor
C. transaction serializability
D. two phase commit
 Binary Locks
• A binary lock can have 2 States or values
• Locked (or 1) and Unlocked (or 0)
Operations used with Binary Locking
• lock_item : A transaction request access to an item by first
issuing a lock_item(X) operation.
– If LOCK(X) =1 or L(X) : the other transaction is forced to
wait.
– If LOCK(X) = 0 or U(x) : it is set to 0 and the transaction is
allowed to access item X.
 Binary Locks
unlock_item : After using the data item the transaction issues an
operation unlock(X), which sets the operation LOCK(X) to 0 i.e.
unlocks the data item so that X may be accessed by another
transactions.
Transaction Rules for Binary Locks
Every transaction must obey the following rules :
•A transaction T must issue the lock(X) operation before
any read(X) or write(X) operations in T.
•A transaction T must issue the unlock(X) operation after all
read(X) and write(X) operations in T.
•If a transaction T will not issue a lock(X) operation if it already
holds the lock on item A.
•If a transaction does not hold the lock on item X, then T will not
issue an unlock(X) operation.
EXAMPLE
Problem here is:
If both T1 and T2 wants to issue read(A).
As read-read is not a conflict, all
transactions can read same data item.
But
If T1 will issue lock(A) then T2 cant
read(A) until T1 release lock i.e.
unlock(A)
Shared and Exclusive Locks or Read/Write
Locks
• The binary lock is too restrictive for data items because at most
one transaction can hold on a given item whether the
transaction is reading or writing.
• To improve it we have shared and exclusive locks in which
more than one transaction can access the same item for
reading purposes .i.e. the read operations on the same item by
different transactions are not conflicting.
In this types of lock, system supports two kinds of lock :
• Exclusive(or Write) Locks and
• Shared(or Read) Locks.
1. Shared Locks
•If a transaction T1 has locked the data item A in shared mode,
then a request from another transaction T2 on A for :
a) Write operation on A : Denied. Transaction T2 has to wait
until transaction T1 unlock A.
b) Read operation on A : Allowed.
2. Exclusive Locks
•If a transaction T1 has locked a data item a in exclusive mode
then request from some another transaction T2 for-
•Read operation on A : Denied
•Write operation on A : Denied
Compatibility table

Request 
S X
Grant S Yes No
X No No
• Operations Used with Shared and Exclusive Locks
• Read_lock(A) or s(A)
• Write_lock(A) or X(A)
• Unlock(X) or U(A)
Locks
• If a transaction acquires a shared lock, then it can
perform .......... operation.
• A. read
• B. write
• C. read and write
• D. update
• If a transaction obtains a shared lock on a row, it
means that the transaction wants to ..... that row.
• A. write
• B. insert
• C. execute
• D. read
The Two-Phase Locking Protocol
 The Two-Phase Locking Protocol
• Need of 2 Phase Locking
• Binary locks or shared and exclusive locks in
transaction does not guarantee serializability of
schedules on its own.
• For example, consider a banking transaction where
the read write locking rules are used, but we get a
non serializable schedule which give incorrect
result.
• In this scheme, each transaction makes lock and unlock request
in 2 phases :
• A Growing Phase( or An Expanding Phase or First Phase)
 : In this phase, new locks on the desired data item can be
acquired but none can be released.
• A Shrinking Phase (or Second Phase) : In this phase, existing
locks can be released but no new locks can be acquired.
• A 2 phase locking always results serializable schedule but it
does not permit all possible serializable schedules i.e. some
serializable schedules will be prohibited by the protocol.
EXAMPLE
• Cascading rollback may occur in Two phase locking so
in order to avoid it following variations on two
phase locking is used:

• Strict two-phase locking : Here a transaction must hold all

its exclusive locks till it commits/aborts.
• Rigorous two-phase locking : is even stricter: here all locks
are held till commit/abort. In this protocol transactions can be
serialized in the order in which they commit.
 Time Stamp Based Protocol
• In timestamp based protocols, the system itself tries to detect
possible inconsistency during concurrent execution and
recovers from it or avoids it.
• In it, for every transaction the system executes, the system
gives the timestamp to that transaction i.e. it provides a set of
timestamps to every transaction Ti by unique timestamp( any
integer value) which is denoted by TS(Ti) where TS is
timestamp of Ti.
 Time Stamp Based Protocol
What is TS(Ti) ??

•Whenever a transaction begins to execute that is just

prior to its execution it is provided a unique timestamp.
This timestamp may be a system related actual real time
stamp which is based on the system time or it may just
be a counter.
• Therefore if we have,TS(Ti) < TS(Tj)
• then it means that transaction Ti starts its
execution before Tj in the system.
• So a timestamp indicates when this transaction will
starts.
• The time stamp based protocols will try to check
whether the concurrent execution may be
consistent or not, or the schedule that occurs must
be atleast conflict equivalent to Ti followed by Tj to
the serial schedule Ti followed by Tj.
• Conflict Operations are allowed in the Timestamp
ordering schedule,  but they must have the order
given by the timestamp. If they do not satisfy the
order, then Rollback of transaction may or may not
be performed.
• For Every data item which will be shared, we have got
two timestamps :
W-Timestamp(Q) or WTS(Q) :
• W-Timestamp(Q) denotes the largest TS or Time Stamp
value of any transaction that successfully executes
Write(Q).
R-Timestamp(Q) or RTS(Q) :
• R-Timestamp(Q) denotes the largest TS or TimeStamp
value of any transaction that successfully executes
Read(Q).
TimeStamp ordering Protocol

• Unique value is assigned to every transaction

• Tells the order (when transactions enter into the system)

• Read_TS(RTS)=Last(latest) transaction number which

performed Read successfully.

• Write_TS(WTS)=Last(latest) transaction number which

performed write successfully.
 TimeStamp ordering Protocol
T1 T2 T3
A B C
R(A)
RTS 0 0 0
R(B)
WTS 0 0 0
W(C)
R(B)
R(C)
W(B)
W(A)
Which transaction is rolled back?

• Rules
T1 T2 T3
R(A)
R(B)
W(C)
R(B)
R(C)
W(B)
W(A)

A B C
RTS 0 0 0
WTS 0 0 0
example
example
Deadlock Handling
DEADLOCK
 Deadlock in Transaction
• Deadlock occurs when each transaction T in a set of
2 or more transactions is waiting for some item that
is locked by some other transaction T’ in the set.
• Hence, each transaction in the set is on a waiting
queue, waiting for one of the other transaction in
the set to release the lock on an item.
EXAMPLE
• System is deadlocked if there is a set of transactions such
that every transaction in the set is waiting for another
transaction in the set.

• Deadlock prevention protocols ensure that the system will

never enter into a deadlock state. Some prevention
strategies :
– Require that each transaction locks all its data items before it
begins execution (predeclaration).
– Impose partial ordering of all data items and require that a
transaction can lock data items only in the order specified by the
partial order (graph-based protocol).
 More Deadlock Prevention Strategies
• Following schemes use transaction timestamps for the sake of
deadlock prevention alone.

• wait-die scheme — non-preemptive

– older transaction may wait for younger one to release data item.
Younger transactions never wait for older ones; they are rolled back
instead.
– a transaction may die several times before acquiring needed data item
• wound-wait scheme — preemptive
– older transaction wounds (forces rollback) of younger transaction
instead of waiting for it. Younger transactions may wait for older ones.
– may be fewer rollbacks than wait-die scheme.
 Deadlock Recovery
• When deadlock is detected :
– Some transaction will have to rolled back (made a victim)
to break deadlock. Select that transaction as victim that
will incur minimum cost.
– Rollback -- determine how far to roll back transaction
• Total rollback: Abort the transaction and then restart it.
• More effective to roll back transaction only as far as
necessary to break deadlock.
– Starvation happens if same transaction is always chosen as
victim. Include the number of rollbacks in the cost factor to
avoid starvation
 Starvation in Deadlock (Livelock)
• The indefinite waiting of a transaction is called
as starvation.
• Starvation occurs when a transaction cannot
proceed for an indefinite period of time while other
transactions in the system continue normally.