Concurrency

Control
BOOK REFERRED : CHAPTER 15 (KORTH, 6 T H EDITION)
Concurrency
Allowing many transactions to access the same database at the same time.
Some kind of control mechanism is needed to ensure that concurrent transactions do not
interfere with each other.
The goal is to develop concurrency control protocols that will assure serializability.
Three Concurrency Problems
1. Lost Update
2. Uncommitted Dependency
3. Inconsistent Analysis
It is the logical possibility of each of these that demands the need for concurrency control. The
problems arise from two or more transactions reading or writing on the same part of the same
database.
Lost Update Problem
Time User 1 (Trans A) User2 (Trans B)
1 Retrieve t
2 Retrieve t
3 Update t
4 Update t
5
6
7

t is a tuple in a table retrieved by both users in the course of both transactions

Transaction A loses an update at time 4, because Transaction B overwrites it without
even looking at it.
Uncommitted Dependency
Time User 1 (Trans A) User 2 (Trans B)

1 Update t
2 Retrieve t
3 Rollback
4
5
6 Update t
7 Update t
8 Rollback

Here are two versions of this problem. In each one (Times 1-3 and 6-8) Transaction A
is dependent on an uncommitted change made by Transaction B which is lost on
Rollback.
 Inconsistent Analysis
Initially: Acc1 = 40; Acc2 = 50; Acc3 = 30;
Time User 1 (Trans A) User 2 (Trans B)
1 Retrieve Acc 1 :
Sum = 40
2 Retrieve Acc2 :
Sum = 90
3 Retrieve Acc3 :
4 Update Acc3:
30 → 20
5 Retrieve Acc1:
6 Update Acc1:
40 → 50
7 commit
8 Retrieve Acc3:
Sum = 110 (not 120)
 Lock-Based Protocols
A lock is a mechanism to control concurrent access to a data item
Data items can be locked in two modes:
1. exclusive (X) mode. Data item can be both read as well as written. X-lock is requested using
lock-X instruction.
2. shared (S) mode. Data item can only be read. S-lock is requested using lock-S instruction.

Lock requests are made to concurrency-control manager. Transaction can proceed only after
request is granted.
Lock-Based Protocols (Cont.)
Lock-compatibility matrix

A transaction may be granted a lock on an item if the requested lock is compatible with locks
already held on the item by other transactions.
Any number of transactions can hold shared locks on an item,
◦ but if any transaction holds an exclusive on the item no other transaction may hold any lock on the
item.

If a lock cannot be granted, the requesting transaction is made to wait till all incompatible locks
held by other transactions have been released. The lock is then granted.
Lock-Based Protocols (Cont.)
Example of a transaction performing locking:
T2: lock-S(A); T1: lock-X(B);
read(B);
read (A); B := B − 50;
unlock(A); write(B);
unlock(B);
lock-S(B);
lock-X(A);
read (B); read(A);
A := A + 50;
unlock(B);
write(A);
display(A+B) unlock(A)
A locking protocol is a set of rules followed by all transactions while requesting and releasing
locks. Locking protocols restrict the set of possible schedules.
Lost Update ‘solved’
Time User 1 (Trans A) User2 (Trans B)
1 Retrieve t (get S-lock on t)
2 Retrieve t (get S-lock on t)
3 Update t (request X-lock on t)
4 wait Update t (request X-lock on t)
5 wait wait
6 wait wait
7

No update is lost but the result is deadlock – see later how to deal with this.
Uncommitted Dependency
‘solved’
Time User 1 (Trans A) User 2 (Trans B)

1 Update t (get X-lock on t)

2 Retrieve t (request S-lock on t) -
3 wait -
4 wait -
5 wait Commit / Rollback
(releases X-lock on t)
6 Resume: Retrieve t
(get S-lock on t)
7 -
8

A resolution of the first version of the problem. Second version is similar (check this!).
Inconsistent Analysis ‘solved’
Time User 1 (Trans A) User 2 (Trans B)

1 Retrieve Acc1 : (get S-lock)

Sum = 40
2 Retrieve Acc2 : (get S-lock)
Sum = 90
3 Retrieve Acc3: (get S-lock)

4 Update Acc3: (get X-lock)

30 → 20
5 Retrieve Acc1: (get S-lock)
6 Update Acc1: (request X-lock)
wait
7 Retrieve Acc3: wait
(request S-lock) wait
wait wait
Pitfalls of Lock-Based Protocols
Consider the partial schedule

Neither T3 nor T4 can make progress — executing lock-S(B) causes T4 to wait for T3 to release its lock on B,
while executing lock-X(A) causes T3 to wait for T4 to release its lock on A.
Such a situation is called a deadlock.
◦ To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.
 Pitfalls of Lock-Based Protocols
T1 : Lock - X(A) T2 : Lock - S(A) T1 T2
Read(A) Read(A) Lock - X(A)
A = A – 100 Unlock - S(A) Read(A)
Write(A) Lock - S(B) A = A – 100
Unlock - X(A) Read(B) Write(A)
Unlock - X(A)
Lock - X(B) Unlock - S(B)
Read(B) Display A + B
Lock - S(A)
B = B + 100 Read(A)
Write(B) Unlock - S(A)
Unlock - X(B) Lock - S(B)
Consider A = 1000 and B = 500 Read(B)
Unlock - S(B)
Sum of A + B should be preserved i.e. Display A + B
1500, both in serial as well as concurrent
transaction. Hence, the schedule is not
serializable. Lock - X(B)
Read(B)
Problem found : “Locks should be kept till B = B + 100
the end, unlocking early creates Write(B)
Unlock - X(B)
inconsistency”.
The Two-Phase Locking Protocol
This is a protocol which ensures conflict-serializable schedules.
Phase 1: Growing Phase
◦ transaction may obtain locks
◦ transaction may not release locks

Phase 2: Shrinking Phase

◦ transaction may release locks
◦ transaction may not obtain locks
Example of two-phase locking
protocol

T3: lock-X(B); T4: lock-S(A); The unlock instructions do

read(B); read(A); not need to appear at the
end of the transaction.
B := B − 50; lock-S(B);
write(B); read(B); For example, in the case
lock-X(A); display(A + B); of transaction T3, we
read(A); unlock(A); could move the unlock(B)
A := A + 50; unlock(B). instruction to just after the
write(A); lock-X(A) instruction, and
unlock(B); still retain the two-phase
unlock(A). locking property.
 Lock Conversions
Two-phase locking with lock conversions:
– First Phase:
◦ can acquire a lock-S on item
◦ can acquire a lock-X on item
◦ can convert a lock-S to a lock-X (upgrade)

– Second Phase:
◦ can release a lock-S
◦ can release a lock-X
◦ can convert a lock-X to a lock-S (downgrade)
Concept of Locking Protocol
Let {T0, T1, . . . , Tn} be a set of transactions participating in a schedule S. We say that Ti
precedes Tj in S, written Ti → Tj, if there exists a data item Q such that Ti has held lock mode A
on Q, and Tj has held lock mode B on Q later, and comp(A,B) = false. If Ti →Tj , then that
precedence implies that in any equivalent serial schedule, Ti must appear before Tj .
We say that a schedule S is legal under a given locking protocol if S is a possible schedule for a
set of transactions that follows the rules of the locking protocol.
We say that a locking protocol ensures conflict serializability if and only if all legal schedules are
conflict serializable; in other words, for all legal schedules the associated → relation is acyclic.
Ensuring serializability
The protocol assures serializability. It can be proved that the
transactions can be serialized in the order of their lock points (i.e., the
point where a transaction acquired its final lock).
T1 T2 T3

LP

LP

LP

Serializability can be ensured in terms of equivalent serial schedule by following

the sequence of lock points i.e. in above case T1  T3  T2
TPLP – does not ensure cascadeless schedules

Each transaction observes the two-phase locking protocol, but the failure of T5 after the read(A) step of T7
leads to cascading rollback of T6 and T7.
Also, Two-phase locking does not ensure freedom from deadlocks.
Problems with 2-phase locking
protocol
Unnecessary wait due to early lock
Deadlock T1 T2
Cascading rollback
Lock – X(A)
T1 T2 R(A)
W(A)
Lock-X(B)
Lock – X(B)
Read(B) . Lock – S (A)
Write(B) . Has to wait till all
. the operations of
Lock-S(A)
. T1 gets over to
Read(A) release the locks
Lock-X(B)
Lock-X(A) .
. .
. .
The Two-Phase Locking Protocol
Two-phase locking does not ensure freedom from deadlocks.
Cascading roll-back is possible under two-phase locking. To avoid this, follow a modified protocol
called strict two-phase locking. Here a transaction must hold all its exclusive locks till it
commits/aborts. This requirement ensures that any data written by an uncommitted transaction are
locked in exclusive mode until the transaction commits, preventing any other transaction from reading
the data.

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.

But, they both cannot ensure deadlock.

Basic 2PL, strict 2PL or rigorous
2PL??
Lock – S (A) Lock – S (A) Lock – S (A)
Read (A) Read (A) Read (A)
Lock – X (B) Lock – X (B) Unlock (A)
Read (A) Unlock (A) Lock – X (B)
Read (B) Read (B) Read (B)
B=A+B Write (B) Write (B)
Unlock (A) Commit Unlock (B)
Write (B) Unlock (B) Commit
Unlock (B)
Isolation Levels
It refers to the degree of interference that a given transaction is prepared to tolerate on the part of
concurrent transactions.
If serializability is guaranteed, the only amount of interference that can be possible is none at all!
Isolation level should be maximum possible.
Higher isolation level – less interference – higher concurrency.
Lesser isolation level – high interference – lesser concurrency.
There are four isolation levels :
◦ Read Uncommitted
◦ Read Committed
◦ Serializable
◦ Repeatable Read
Isolation Levels
Serializable is default level.
SERIALIZABLE > REPEATABLE READ > READ COMMITTED > READ UNCOMMITTED
Serializable:- Specifies that all transactions occur in a completely isolated fashion; i.e., as if all
transactions in the system had executed serially, one after the other. The DBMS may execute two or
more transactions at the same time only if the illusion of serial execution can be maintained.
Read Committed:- Allows only committed records to be read and further requires that, between two
reads of a record by a transaction, no other transaction is allowed to update the record.
Read Uncommitted:- Allows only committed records to be read, but does not require even repeatable
reads. For instance, between two reads of a record by the transaction, the records may have been
updated by other committed transactions. i.e. dirty reads are allowed. One transaction may see
uncommitted changes made by some other transaction.
Repeatable Read: Allows even uncommitted records to be read.
Issues with lesser Isolation
Levels
Lesser isolation level violates serializability in three ways:
Dirty Read: Suppose transaction T1 performs an update on some row, transaction T2 then
retrieves that row, and transaction T1 then terminates with rollback. Transaction T2 has then
seen a row that no longer exists.
Nonrepeatable Read: Suppose transaction T1 retrieves a row, transaction T2 then updates that
row, and transaction T1 then retrieves the “same row” again. Transaction T1 has now retrieved
the “same” row twice but seen two different values for it.
Phantoms: Suppose transaction T1 retrieves the set of all rows that satisfy some condition.
Suppose that transaction T2 then inserts a new row satisfying the same condition. If transaction
T1 now repeats its retrieval request, it will see a row that did not previously exist – a “phantom”.
Isolation Levels
Isolation level Dirty reads Non-repeatable reads Phantoms
Read Uncommitted X X X
Read Committed - X X
Repeatable Read - - X
Serializable - - -

"X" means that the isolation level has the problem,

while "-" means that it does not have the problem.
Deadlock Handling
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.
 Deadlock Prevention
Strategies
1. The wait–die scheme is a nonpreemptive technique. When transaction Ti requests a data item
currently held by Tj , Ti is allowed to wait only if it has a timestamp smaller than that of Tj (that is, Ti is
older than Tj ). Otherwise, Ti is rolled back (dies).
◦ For example, suppose that transactions T14, T15, and T16 have timestamps 5, 10, and 15, respectively. If T14
requests a data item held by T15, then T14 will wait. If T16 requests a data item held by T15, then T16 will be
rolled back.

2. The wound–wait scheme is a preemptive technique. It is a counterpart to the wait–die scheme. When
transaction Ti requests a data item currently held by Tj , Ti is allowed to wait only if it has a timestamp
larger than that of Tj (that is, Ti is younger than Tj ). Otherwise, Tj is rolled back (Tj is wounded by Ti ).
◦ Returning to our example, with transactions T14, T15, and T16, if T14 requests a data item held by T15, then the
data item will be preempted from T15, and T15 will be rolled back. If T16 requests a data item held by T15, then
T16 will wait.
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. (older means smaller timestamp) . 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 prevention (Cont.)
Both in wait-die and in wound-wait schemes, a rolled back transactions is
restarted with its original timestamp. Older transactions thus have precedence
over newer ones, and starvation is hence avoided.
Timeout-Based Schemes:
◦ A transaction waits for a lock only for a specified amount of time. If the lock has not been granted within
that time, the transaction is rolled back and restarted,
◦ Thus, deadlocks are not possible.
◦ Too long a wait results in unnecessary delays once a deadlock has occurred.
◦ Too short a wait results in transaction rollback even when there is no deadlock, leading to wasted
resources.
◦ Simple to implement; but starvation is possible. Also difficult to determine good value of the timeout
interval.
Deadlock Detection
Deadlocks can be described as a wait-for graph, which consists of a pair G = (V , E)
◦ V is a set of vertices (all the transactions in the system)
◦ E is a set of edges; each element is an ordered pair Ti Tj.

If Ti  Tj is in E, then there is a directed edge from Ti to Tj, implying that Ti is waiting for Tj to release a
data item.
When Ti requests a data item currently being held by Tj, then the edge Ti  Tj is inserted in the wait-for
graph. This edge is removed only when Tj is no longer holding a data item needed by Ti.
The system is in a deadlock state if and only if the wait-for graph has a cycle. Must invoke a deadlock-
detection algorithm periodically to look for cycles.
Deadlock Detection (Cont.)

Wait-for graph without a cycle Wait-for graph with a cycle

Precedence vs. Wait-For Graphs
Precedence graph Wait-for Graph
◦ Each transaction is a vertex
◦ Each transaction is a vertex
◦ Arcs from T2 to T1 if
◦ Arcs from T1 to T2 if
◦ T1 read-locks X then T2 tries to write-lock it
◦ T1 reads X before T2 writes X
◦ T1 write-locks X then T2 tries to read-lock it
◦ T1 writes X before T2 reads X
◦ T1 write-locks X then T2 tries to write-lock
◦ T1 writes X before T2 writes X it
Example
T1 Read(X) T1

T2 Read(Y)
T1 Write(X)
T2 T3
T2 Read(X)
T3 Read(Z)
Wait for graph
T3 Write(Z)
T1 Read(Y)
T3 Read(X) T1
T1 Write(Y)

T2 T3

Precedence graph
Example
T1 Read(X) T1

T2 Read(Y)
T1 Write(X)
T2 T3
T2 Read(X)
T3 Read(Z)
Wait for graph
T3 Write(Z)
T1 Read(Y)
T3 Read(X) T1
T1 Write(Y)

T2 T3

Precedence graph
Example
T1 Read(X) T1

T2 Read(Y)
T1 Write(X)
T2 T3
T2 Read(X)
T3 Read(Z)
Wait for graph
T3 Write(Z)
T1 Read(Y)
T3 Read(X) T1
T1 Write(Y)

T2 T3

Precedence graph
Example
T1 Read(X) T1

T2 Read(Y)
T1 Write(X)
T2 T3
T2 Read(X)
T3 Read(Z)
Wait for graph
T3 Write(Z)
T1 Read(Y)
T3 Read(X) T1
T1 Write(Y)

T2 T3

Precedence graph
Example
T1 Read(X) read-locks(X) T1

T2 Read(Y) read-locks(Y)
T1 Write(X) write-lock(X)
T2 T3
T2 Read(X) tries read-lock(X)
T3 Read(Z)
Wait for graph
T3 Write(Z)
T1 Read(Y)
T3 Read(X) T1
T1 Write(Y)

T2 T3

Precedence graph
Example
T1 Read(X) read-locks(X) T1

T2 Read(Y) read-locks(Y)
T1 Write(X) write-lock(X)
T2 T3
T2 Read(X) tries read-lock(X)
T3 Read(Z) read-lock(Z)
Wait for graph
T3 Write(Z) write-lock(Z)
T1 Read(Y) read-lock(Y)
T3 Read(X) tries read-lock(X) T1
T1 Write(Y)

T2 T3

Precedence graph
Example
T1 Read(X) read-locks(X) T1

T2 Read(Y) read-locks(Y)
T1 Write(X) write-lock(X)
T2 T3
T2 Read(X) tries read-lock(X)
T3 Read(Z) read-lock(Z)
Wait for graph
T3 Write(Z) write-lock(Z)
T1 Read(Y) read-lock(Y)
T3 Read(X) tries read-lock(X) T1
T1 Write(Y) tries write-lock(Y)

T2 T3

Precedence graph
Deadlock Recovery
When deadlock is detected, three actions can be taken :
1. Selection of a victim. Given a set of deadlocked transactions, we must determine which
transaction (or transactions) to roll back to break the deadlock. We should roll back those
transactions that will incur the minimum cost. Unfortunately, the term minimum cost is not a
precise one. Many factors may determine the cost of a rollback, including:
a. How long the transaction has computed, and how much longer the transaction will compute
before it completes its designated task?
b. How many data items the transaction has used?
c. How many more data items the transaction needs for it to complete?
d. How many transactions will be involved in the rollback?
Deadlock Recovery (Contd…)
When deadlock is detected, three actions can be taken :
2. Rollback. Once we have decided that a particular transaction must be rolled back, we must
determine how far this transaction should be rolled back. The simplest solution is a total rollback:
Abort the transaction and then restart it. However, it is more effective to roll back the transaction only
as far as necessary to break the deadlock. Such partial rollback requires the system to maintain
additional information about the state of all the running transactions.
Deadlock Recovery (Contd…)
When deadlock is detected, three actions can be taken :
3. Starvation. In a system where the selection of victims is based primarily on cost factors, it
may happen that the same transaction is always picked as a victim. As a result, this
transaction never completes its designated task, thus there is starvation. We must ensure that
a transaction can be picked as a victim only a (small) finite number of times. The most
common solution is to include the number of rollbacks in the cost factor.
Thank You!!