Lecture3
Concurrency Control Techniques
Mohamed al-jaafari
Lecture3 – Spring 2023
For each the following schedules determine whether the schedule is
conflict-Serializable or view serializable. Justify your answers.
T1 T2 T3
Write(C)
Write(B)
i Read(B)
Read(C)
Write(C)
Read(C)
- It is conflict serializable ? Why
- It is view serializable ? Why
T1 T2 T3
Write(C)
Write(B)
Read(B)
Read(C)
Write(C)
Read(C)
- It is conflict serializable : Yes
- Why ? Precedence graph
T1 T2 T3
Graph has no cycle
- It is view serializable : Yes
- Why ? If it is conflict serializable it is also view serializable
T1 T2 T3
Read(C)
Write(C)
ii
Write(C)
Read(B)
Write(C)
- It is conflict serializable ? Why
- It is view serializable ? Why
It is conflict serializable : No
Why ? Precedence graph :
T1 T2 T3
Graph has a cycle
There exists a blind write W3(C) in the given schedule S.
T2 firstly reads C and T1 firstly updates C So , T2 must execute
before T1 . Dependency T2 T1.
Final updation on C is made by the transaction T3. So , T3 must
execute after all transactions. Thus , we get the dependency
(T1,T2)T3
There exists no writer – read sequence.
Clearly there exists a no cycle in the dependency graph.
Thus, we conclude that the given schedule S is view serializable
T1 T2
- It is view serializable : Yes
- Why ? T2 read initial C , T1 reads initial B T3
T3 writes final C , in both schedules
Headlines :
What is Concurrency Control ?
Why Concurrency Control is Needed ?
Lock-Based Protocols
Graph – Based Protocols
Timestamp-Based Protocols
Validation-Based Protocols
Multiple Granularity
What is 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.
Why Concurrency Control is needed ?
The Lost Update Problem
This occurs when two transactions that access the same database items
have their operations interleaved in a way that makes the value of some
database item incorrect and makes the database inconsistent.
T1 Time T2 X
read_item(X); t1 1000
X=X+100; t2 read_item(X); 1000
write_item(X) t3 X=X+50; 1100
; t4 write_item(X); 1050
__________ _______
Why Concurrency Control is needed ?
The Uncommitted Dependency (Dirty Read Problems)
This occurs when one transaction updates a database item and then the
transaction fails for some reason.
T1 Time T2 X
t1 Begin_transc 1000
t2 read_item(X); 1000
t3 X=X+50; 1000
Begin_transc t4 write_item(X); 1050
read_item(X); t5 rollback
________ t6
t7 1000
t8
Why Concurrency Control is needed ?
The Uncommitted Dependency (Dirty Read Problems)
T1 Time T2 X
t1 Begin_transc 1000
t2 read_item(X); 1000
t3 X=X+50; 1050
Begin_transc t4 write_item(X); 1050
read_item(X); t5 1050
X=X+100; t6 rollback 1000
write_item(X); t7 1150
commit t8
Why Concurrency Control is needed ?
The Inconsistent Analysis Problem
If one transaction is calculating an aggregate summary function on a
number of records while other transactions are updating some of these
records, the aggregate function may calculate some values before they
are updated and others after they are updated.
Why Concurrency Control is needed ?
The Inconsistent Analysis Problem
T1 Time T2 X3 X2 X1
Begin_transc t1 300 200 100
read_item(X1); t2
Sum=X1=100; t3
read_item(X2); t4
Sum= Sum + X2; t5 Begin_transc
t6 read_item(X3);
t7 X3=X3-100;
t8 write_item(X3); 200 200 100
t9 read_item(X1);
t10 X1=X1+100;
t11 write_item(X1); 200 200 200
t12 Commit;
read_item(X3); t13
Sum=Sum+200; t14
Commit;
Why Concurrency Control is needed ?
Unrepeatable Read
This problem occurs when in a transaction, two different values are read
for the same database item.
T1 T2
R(X)
R(X)
X = X +100
W(X)
R(X)
Why Concurrency Control is needed ?
Phantom Read
This problem occurs when a transaction reads some variable from the
buffer and when it reads the same variable later, it finds that the variable
does not exist.
T1 T2
R(A)
R(A)
DELETE(A)
R(A)
Lock-Based Protocols
A lock is a mechanism to control concurrent access to a data item
Locking is an operation which secures
(a) Permission to read
(b) 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 transaction.
Lock and Unlock are Atomic operations
Levels of Locking in DBMS
• Indicates level of lock use
• Locking can take place at following levels:
– Database
– Table
– Page
– Row
– Field (attribute)
Levels of Locking in DBMS
• Database-level lock
– Entire database is locked
• Table-level lock
– Entire table is locked
• Page-level lock
– Entire diskpage is locked
Levels of Locking in DBMS
• Row-level lock
– Allows concurrent transactions to access different rows of
same table
• Even if rows are located on same page
• Field-level lock
– Allows concurrent transactions to access same row
• Requires use of different fields (attributes) within the
row
Database-level lock
Table level lock
Page level lock
Row level lock
Lock - Based Protocols
Two locks modes :
(a) Shared (read) (b) exclusive (write)
Shared mode : shared lock (X) – Lock S
More than one transaction can apply share on X for reading its value but
no write lock can be applied on X by any other transaction.
Exclusive mode : Write lock (X) – 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. S X
S
Lock Compatibility (Conflict Matrix) :
X
Lock - Based Protocols
Example of transaction performing locking :
T1 : lock-S(A);
read(A);
unlock(A);
lock_S(B);
read(B);
unlock(B);
Display(A+B);
Locking as shown above is not sufficient to guarantee serializability
If A and B get update in between the read of A and B the displayed
sum wrong.
A locking protocol is a set of rules followed by all transactions while
requesting and releasing locks.
Locking Manager
Lock Manager :
Managing locks on data items.
Lock Table :
Lock manager uses it to store the identify or 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 item
T1 X1 Read Next
Lock Table
• Black rectangles indicate granted locks, white
ones indicate waiting requests.
• Lock table also records the type of lock
granted or requested.
• New request is added to the end of the queue
of requests for the data item, and granted if it
is compatible with all earlier locks.
• Unlock requests result in the request being
deleted, and later requests are checked to see
if they can now be granted.
If transaction aborts, all waiting or granted requests of the
transaction are deleted
lock manager may keep a list of locks held by each transaction, to
implement this efficiently
Locking Conversion
Lock upgrade : existing read lock to write lock
shared Exclusive
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
Exclusive shared
Ti has write-lock(X) (* no transaction can have any lock on X*)
Convert write-lock(X) to read-lock(X)
Automatic Acquisition of Locks
• A transaction Ti issues the standard read/write instruction, without
explicit locking calls.
• The operation read(D) is processed as:
if Ti has a lock on D then
read(D)
else
begin
if necessary wait until no other transaction has
a lock-X on D
grant Ti a lock-S on D;
read(D)
end
Automatic Acquisition of Locks (Cont.)
• write(D) is processed as:
if Ti has a lock-X on D then
write(D)
else
begin
if necessary wait until no other trans. has any lock on D,
if Ti has a lock-S on D
then
upgrade lock on D to lock-X
else
grant Ti a lock-X on D
write(D)
end;
• All locks are released after commit or abort.
The Two Phase Locking Protocol – 2PL
Two Phases
(a) Locking (Growing)
(b) Unlocking (Shrinking)
Locking (Growing) Phase :
A transaction applies locks (read or write) on desired data items one at a
time. T1
Lock-s(A)
R(A)
Lock_x(B)
W(B)
………
……..
Lock-s(C)
R(C)
The Two Phase Locking Protocol – 2PL
Unlocking(Shrinking) Phase :
A transaction unlocks its locked data items one at a time.
T1
Lock-s(A)
R(A)
Unlock(A)
Lock_x(B)
R(B)
W(B)
Unlock(B)
Lock-s(C)
The Two Phase Locking Protocol – 2PL
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
T1
Lock-s(A)
R(A)
Lock_x(B)
R(B)
W(B)
Unlock(A) Shrinking phase
Lock-s(C) X
The Two Phase Locking Protocol – 2PL
T1 T2
LOCK-X(A) Growing Phase
LOCK-X(B)
LOCK-S(C)
UNLOCK-X(B) Shrinking Phase
LOCK-S(D) x
LOCK-X(B)
UNLOCK-S(C)
LOCK-X(C)
Two Phase Locking Protocol
T1 T2 Result
read_lock (Y); X=50 ; Y =50
read_item (Y); Nonserializable
unlock (Y); because it violated
read_lock (X); two phase policy
read_item (X);
unlock (X);
write_lock (Y);
Time 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);
The Two Phase Locking Protocol – 2PL
Basic : Transaction locks data items incrementally. This may cause
deadlock which is dealt with.
Conservative : Prevents deadlock by locking all desired data item
before transaction begins execution.
Strict : A more stricter version of basic algorithm where unlocking is
performed after a transaction terminates (commits or abort and rolled
–back) all its exclusive locks this is the most commonly used two-
phase locking algorithm
Problems with Locking Based Protocols
Rigorous : is even stricter here all locks (shared and exclusive) are
held till commit/abort. in this protocol transactions can be serialized in
the order in which they commit
Problems with Locking Based Protocols
Deadlock
T1 T2
Read_lock(Y);
Read_item(Y);
Read_lock(X); T1 and T2 did follow two-phase
Read_item(X); policy but they are deadlock
write_lock (X);
(waits for X) Write_lock (Y);
(wait for Y)
Such a situation is called a deadlock.
Deadlock Prevention
A transaction locks all data items it refers to before it begins
execution.
This way of locking prevents deadlock since a transaction never waits
for a data item.
The conservative , strict two-phase locking uses this approach.
Deadlock Detection and Resolution
In this approach , deadlocks are allowed to happen . The scheduler
maintains a wait-for-graph for detecting cycle. If a cycle exists , then
one transaction involved in the cycle is selected (victim) and rolled-
back.
A wait-for graph is created using the lock table. As soon as a
transaction is blocked ,it is added to the graph. When a chain like: Ti
waits for Tj waits for Tk waits for Ti or Tj occurs , then this creates a
cycle.
Deadlock Detection and Resolution
T26 T28 T26 T28
T25 T25
T27 T27
wait-for graph without a cycle wait-for graph with a cycle
deadlock
Selection of a victim
many factors may determine the cost of a rollback including
How long the transaction has computed , and how much longer the
transaction will compute before it completes its designated task.
How many data items the transaction has used.
How many more data items the transaction needs for complete.
How many transactions will be involved in the rollback.
Starvation
Starvation occurs when a particular transaction consistently waits or
restarted and never gets a chance to proceed further.
In a deadlock resolution it is possible that the same transaction may
consistently be selected as victim and rolled-back.
This limitation is inherent in all priority based scheduling
mechanisms.
Graph – Based Protocols
Graph-based protocols are an alternative to two-phase locking
Based on the knowledge of additional information on how items are
accessed.
To acquire such a prior knowledge , we impose a partial ordering
on the set D={d1 , d2 ,…dn} of all data items.
If di dj then any transaction accessing both di and dj must access
di before accessing dj.
It implies that the set D may now be viewed as a directed acyclic
graph , called a database graph.
The tree-protocol is a simple kind of graph protocol
The Tree Protocol
A
B C
F
D
E
G H I
Rule1: Only exclusive locks(X-Lock) are allowed in the Tree
protocol.
Rule2: The first lock by Ti may be on any data item. Subsequently ,
a data Q can be locked by Ti only if the parent of Q is currently
locked by Ti.
Rule3: Data items may be unlocked at any time.
Rule4: A data item that has been locked and unlocked by Ti cannot
subsequently be relocked by Ti
Graph – Based Protocols
The tree protocol ensures conflict serializability as well as freedom
from deadlocks.
All schedules that are legal under the tree protocol are conflict
serializable.
The tree-locking protocol has two advantages as compared to the
two-phase locking protocol.
Protocol is deadlock- free , so no rollbacks are required.
Unlocking may occur earlier in the tree-locking protocol than in the
two-phase locking protocol.
Shorter waiting times , and increase in concurrency.
Graph – Based Protocols
The tree-locking protocol has the drawback that , in some cases , a
transaction may have to lock data items that is does not access (e.g .
A transaction that needs to access A and J must lock not only A and J
but also B , D,H).
Increased locking overhead , and possible additional waiting time
potential decrease in concurrency.
Schedules that are not possible under two-phase locking may be
possible under tree protocol and vice versa.
Example
T10:lock-X(B);lock-X(E);lock-X(D);unlock(B);unlock(E);lock-X(G);
unlock(D);unlock(G).
T11:lock-X(D);lock-X(H);unlock(D);unlock(H).
T12:lock-X(B);lock-X(E);unlock(B);unlock(E).
T13:lock-X(D);lock-X(H);unlock(D);unlock(H).
T10 T11 T12 T13
Example Lock-x(B)
lock-x(D)
lock-x(H)
unlock-x(D)
lock-x(E)
lock-x(D)
unlock-x(B)
unlock-x(E)
lock-x(B)
lock-x(E)
unlock-x(H)
lock-x(G)
unlock(D) lock-x(D)
lock-x(H)
unlock-x(D)
unlock-x(H)
unlock-x(E)
unlock-x(B)
unlock(G)
