Chapter – 4
Concurrency control techniques
1
Concurrency control
• Concurrency control: the process of managing
simultaneous operations on the shared database without
having them interfere with each other.
• Conc. Control techniques are used to ensure the
serializability of transactions.
• Remember the 3 potential problems of concurrency.
• Lost update problem
• Dirty read problem
• Incorrect summary problem
2
Purposes of Concurrency control
• To enforce Isolation.:- one transn is not interleaving another
transn
• To preserve Database consistency
• To resolve Read-Write, write-read and Write-Write conflict.
• How do we control concurrency?
3
Concurrency control
• There are two Concurrency control Techniques :
– Lock based protocol
– Timestamp protocol
4
Lock based protocol
• A lock is a variable that guarantees exclusive use of a data
item to current transaction. It includes two operations.
– To access a data item(lock acquire- lock(x))
– After completion of transaction (release lock-unlock(x))
• Locking is a procedure used to control concurrent access
to data or to ensure serialisability of concurrent
transactions
• This may deny access to other transactions to prevent
incorrect results
• All data item must be accessed in mutually exclusive
manner.
5
Two types of locks
• Two types of lock
– Binary lock
– Shared/Exclusive lock
• The lock manager in the DBMS assigns locks and
records them in the data dictionary.
• Locks are released on commit/rollback.
6
Binary lock
• Binary lock: binary lock have two states or values: locked
and unlocked (or 1 and 0, for simplicity)
• Two operations, lock_item and unlock_item, are used with
binary locking
• A transaction requests access to an item X by first
issuing a lock_item(X) operation
– If LOCK(X) = 1, the transaction is forced to wait
– If LOCK(X) = 0, it is set to 1 (the transaction locks the item) and
the transaction is allowed to access item X
7
Binary lock
• 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.
– 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 8
Shared/exclusive lock
• Shared lock (read lock) is written as lock-S(data item).
• Exclusive lock (write lock) is written as lock-X(data item)
• Read lock allows several transactions simultaneously to read a
resource (but no transactions can change it at the same time)
• Write lock allows one transaction exclusive access to write to a
resource. no other transaction can read this resource at the same time.
• A transaction may not acquire a lock on any resource that is write-
locked by another transaction.
• A transaction may not acquire a write-lock on a resource that is locked
by another transaction.
• If the requested lock is not available, transaction waits. 9
Compatibility b/n lock modes
Read Write
Read S X
Or
Write X X
S X
S True False
X False False
10
Lock based protocol
• Any no of transactions can hold shared lock on an item
but exclusive lock can be hold only by one trans at a time.
T1 T2
Lock-X(B)
R(B)
B-50
W(B)
Unlock(B)
Lock-S(B) Lock-S(B)
R(B) R(B)
Unlock (B) Unlock(B)
11
Lock based protocol
• T1: Transfer AB and T2: Display (A+B)
T1
Lock-x(A) T2
R(A)
Lock-S(A)
R(A)
A:-A-100
Unlock(A)
W(A)
Lock-S(B)
Unlock(A)
R(B)
Lock-x(B)
Unlock(B)
R(B)
Display(A+B)
B:-B+100
W(B)
Unlock(B) 12
Conversion of locks
• Upgrading :- Read-lock Write-Lock
– This means from shared to exclusive lock.
• Downgrading:- Write lock Read-lock.
– This from exclusive lock to shared lock
13
Conversion of locks
If a transn need to read data item x, it acquires shared lock on x.
lock-s(x)
Read(x)
Meanwhile, if we want to write operation on data item x so, before
we perform write operation we have to upgrade this lock (lock-s).
Lock-s(x)
Read(x)
Lock-x(x)
Write(x)
Similarly if the write is over I want to perform read or some other
trans read it would not be access because its exclusively locked, so
we downgrade the lock by adding lock-s after write operation.
Lock-x(x)
Write(x)
lock-s(x)
Read(x)
14
Problem in simple Lock
• T1: Transfer AB and T2: Display (A+B)
T1 T2
Lock-x(A)
R(A) T1
A=A-100 Lock-x(B)
W(A) R(B)
Unlock(A) B=B+100
Lock-S(A) W(B)
R(A) Unlock(B)
Unlock(A) Lock-S(B)
Lock-S(B) R(B)
R(B)
Unlock(B) 15
Problem in simple Lock
• If at start, A= 1000 B= 500, after W(x) result should be:
A=900, and display (A+B) is executes the result is 1400.then
next
– In T1 it executes lock-x(x) and read the value which is 500
then add 100 to B then write back which become 600. T2
read wrong value
• inconsistency in the database
• However, result should be 1500. this problem is due to
intermixing of the operations.
16
Problem in simple Lock
• The problem is that transactions release locks too soon,
resulting in loss of isolation and atomicity. This means the
T1 release data item A (unlock(A)) before lock-x(B) so
operation L-s(A) is not guaranteed by T1 because A is
already locked by T2.
• To guarantee serializability, need an additional protocol
concerning the positioning of lock and unlock operations in
every transaction.
17
Two phase Locking protocol
• It requires both locks and unlocks being done in two
phases. (2PL)
• 2PL has two phases one is growing where all the locks are
being acquired by the transaction, and second phase is
shrinking ,where the locks held by the transaction are
being released.
18
Two-Phase Locking
Growing phase: Shrinking phase:
locks are acquired on where locks are released. i.e
resources i.e New locks on exiting locks are released
items can be acquired. but but no new lock can be
cannot release any locks. acquired.
19
Two-Phase Locking Protocol
Two-Phase Locking
• One rule in 2pL is if a transaction • T2 request a lock
– WL(x)
release one lock it cant ask any more
– W(x)
lock after reaching lock point. – RL(y)
• This is to enforce serialibility. Ex – WL(y)
• then release the lock.
• T1:R(x)W(x)R(y)W(y)
T1 will start next
• T2:R(x)W(x)R(y)W(y)
• Then, when both trans came to
system
21
2phase Locking
• What kind of locking the following schedule has?
T1
Lock-s(A)
Read(A)
Lock-x(B)
read(B)
Unlock(A)
Write(B)
Unlock(B)
22
2phase Locking
What is the following schedule?
T2
Lock-s(A)
Read(A)
Lock-x(B)
Read(B)
Write(B)
Unlock(B)
Unlock(A)
commit
23
Problem with 2phase Locking
• 2PL protocol enforces serializability but may reduce
concurrency due to the ff reasons
– Holding Lock un-necessarily
• Operation can wait even if the data which is no
longer required for other transaction. So there is
unnecessarily wait due to early lock
– Deadlock
– Starvation
24
Problem. Unnecessarily…
• Example
T2 want to read a data item A lock-s(A).
T1 T2
Lock-x(A) But data item A Is Exclusively locked by T1.
R(A) so it is forced to wait until all Operations
W(A) will finish which is Unnecessary Wait
Lock-X(B) because of early lock.
Lock-s(A)
25
Problem…Deadlock
• A system is in a deadlock state if there exists a set of
transactions such that every transaction in the set is
waiting for another transaction in the set.
• Assume both T1 and T2 need data items x and y to
complete the transaction.
T1 T2 T1 waiting T2 to release lock y and
T2 also waiting T1 to release lock On x .
Lock-x(X)
this state is Deadlock state.
X=x+y
Lock-x(Y)
Y=y-x
Lock-s(y)
26 Lock-s(x)
Starvation
• Starvation is another problem occurs when a transaction cannot
proceed for an indefinite period of time while other transactions in
the system continue normally.
• This may occur if the waiting scheme for locked items is unfair,
giving priority to some transactions over others.
• One solution for starvation is to have a fair waiting scheme, such as
using a first-come-first-serve queue; transactions are enabled to
lock an item in the order in which they originally requested the lock
• Starvation can also occur because of victim selection if the
algorithm selects the same transaction as victim repeatedly, thus
causing it to abort and never finish execution the lock
27
Dealing with Deadlock
• 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.
• Hence, each transaction in the set is on a waiting queue, waiting for
one of the other transactions in the set to release the lock on an
item
• Example, when two transactions T1 and T2 are deadlocked in a partial
schedule; T1 is on the waiting queue for X, which is locked by T2,
while T2 is on the waiting queue for Y, which is locked by T1
• Meanwhile, neither T1 nor T2 nor any other transaction can access
items X and Y.
28
Deadlock Prevention Protocols
• We can prevent deadlock using the concept of transaction timestamp
TS(T), which is a unique identifier assigned to each transaction.
• The timestamps are typically based on the order in which
transactions are started
– hence, if transaction T1 starts before transaction T2, then
TS(T1) < TS(T2)
– Notice that the older transaction has the smaller timestamp
value. Two schemes that prevent deadlock are called wait-die and
wound-wait
29
Con..
• 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 as follows:
– Wait-die: 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.
– Wound-wait: If TS(Ti) < TS(Tj), then (Ti older than Tj) abort Tj
(Ti wounds Tj) and restart it later with the same timestamp;
otherwise (Ti younger than Tj) Ti is allowed to wait.
30
Concurrency Control Based on Timestamp Ordering
• Timestamps
– Timestamp is a unique identifier created by the DBMS
to identify a transaction
– Typically, timestamp values are assigned in the order in
which the transactions are submitted to the system.
– So, Timestamp is transaction start time.
– The timestamp of transaction T is denoted by TS(T)
– Concurrency control techniques based on timestamp
ordering do not use locks; hence, deadlocks cannot
occur
31
Multiversion Concurrency Control Techniques
• This technique keeps the old values of a data item when the item is
updated
• When a transaction requires access to an item, an appropriate version
is chosen to maintain the serializability of the currently executing
schedule
• When a transaction writes an item, it writes a new version and the old
version of the item is retained
• Drawback of multiversion techniques is that more storage is needed
to maintain multiple versions of the database items. However, older
versions may have to be maintained anyway for example, for recovery
purposes
32
Multiversion Technique Based on Timestamp Ordering
• In this method, several versions, of each data item X are
maintained. For each version, the value of version and the
following two timestamps are kept:
– read_TS: is the largest of all the timestamps of transactions
that have successfully read version.
– write_TS: is the timestamp of the transaction that wrote the
value of last version .
• Whenever a transaction T is allowed to execute a
write_item(X) operation, a new version of item X is
created, with both the write_TS and the read_TS set to
TS(T)
• Correspondingly, when a transaction T is allowed to read
the value of version Xi, the value of read_TS() is set to
the larger of the current read_TS() and TS(T).
33
Basic timestamp ordering
• Whenever some transaction T tries to issue a read(X) or a write(X)
operation, the basic TSO algorithm compares the timestamp of T
with read_TS(X) and write_TS(X) to ensure that the timestamp
order of transaction execution is not violated.
• The concurrency control algorithm must check whether conflicting
operations violate the TSO in the following two cases:
34
Basic timestamp ordering
1. Transaction T issues a write(X) operation:
a. If read_TS(X) > TS(T) or 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
a timestamp greater than TS(T) has already read or written
the value of item X before T had a chance to write X
b. If the condition in part (a) does not occur, then execute
the write(X) operation of T and set write_TS(X) to
TS(T).
35
Basic timestamp ordering
2. Transaction T issues a read(X) operation:
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) 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(X)
operation of T and set read_TS(X) to the larger of TS(T)
and the current read_TS(X).
36
Validation (Optimistic) Concurrency Control
Techniques
• In this techniques no checking is done while the
transaction is executing
• Updates in the transaction are not applied directly to the
database items until the transaction reaches its end
• During transaction execution, all updates are applied to
local copies of the data items that are kept for the
transaction
• At the end of transaction execution, a validation phase
checks whether any of the transaction’s updates violate
serializability 37
Con…
• If serializability is not violated transaction is committed and the
database is updated from the local copies; otherwise, the transaction
is aborted and then restarted later
• There are three phases for this concurrency control protocol:
– Read phase: A transaction can read values of committed data
items from the database. However, updates are applied only to
local copies
– Validation phase: Checking is performed to ensure that
serializability will not be violated if the transaction updates are
applied to the database
– Write phase: If the validation phase is successful, the
transaction updates are applied to the database; otherwise, the
updates are discarded and the transaction is restarted 38
Granularity of Data Items
• The size of data items is often called the data item granularity
– Fine granularity refers to small item sizes, More lock and unlock
operations will be performed whereas
– Coarse granularity refers to large item sizes
• The larger the data item size is, the lower the degree of
concurrency permitted
– Example, if the data item size is a disk block, a transaction T that needs to
lock a record B must lock the whole disk block X that contains B because a
lock is associated with the whole data item (block)
– If another transaction S wants to lock a different record C that reside in
the same block X, it is forced to wait. If the data item size was a single
record, transaction S would be able to proceed, because it would be locking
a different data item (record).
39
The End
40
