BITS Pilani

Pilani | Dubai Goa | Hyderabad

Module 5.2
Concurrency Control,
Lock-based Protocols and Deadlocks,
Database Recovery

Database Management Systems

 Objective:
Understanding Concurrency control
schemes and implementing serializability
with locks and timestamps; Deadlocks
with suitable examples

Database Management Systems

 Contents:
Concurrency control and Implementing
Serializability
Lock-based protocols and Deadlocks
Timestamp based protocols
Introduction to Database recovery and Log-
based recovery
Checkpointing
Shadow paging

Database Management Systems

 Purpose of 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.

Database Management Systems

 Binary Locks
 A binary lock has two states zero or one (0 or 1)
 L(X) = 1 means the database object X is locked
 L(X) = 0 means the database object X is
unlocked
 Statements:
 Lock(X) – Lock on object X
 UnLock(X) – Unlock on object X

Database Management Systems

Binary Lock Algorithms

Algorithm Lock(X) Algorithm UnLock(X)

{ {
Repeat L(X) = 0;
{ if any T is waiting in queue
if L(X) = 0 then Wake up T.
then L(X) =1. }
} until L(X) = 0.
Wake up T.
}

Database Management Systems

Shared and Exclusive Locks
 Shared lock S(A): If a shared lock is requested
by T, the lock manager grants it provided there is
no exclusive lock on the object A,
i.e. L(A) = 'S'. Lock manager increments the
count of number of read locks on X by one.
 Exclusive lock X(A): If an exclusive lock is
requested by T, the lock manager grants it
provided no other transaction holds a lock on X
i.e. L(A) = 'X'.
 If the request raised by T can not be granted,
then it is inserted into the queue and T is
suspended.
Database Management Systems
Two-Phase Locking Techniques
 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
transactions.
 Lock and Unlock are Atomic operations.

Database Management Systems

Two-Phase Locking Techniques: Essential components

Two locks modes:

(a) shared (read) (b) exclusive (write).

Shared mode: shared lock (X)

More than one transaction can apply share lock on X for
reading its value but no write lock can be applied on X by any
other transaction.

Exclusive mode: Write 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.

Conflict matrix
Read Write
Read

Y N
Write

N N

Database Management Systems

 Two-Phase Locking Techniques: Essential
components
 Lock Manager:

Managing locks on data items.
 Lock table:

Lock manager uses it to store the identify of
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 data item
T1 X1 Read Next

Database Management Systems

 Two-Phase Locking Techniques: Essential
components
 Database requires that all transactions should be
well-formed. A transaction is well-formed if:

It must lock the data item before it reads or writes to
it.

It must not lock an already locked data items and it
must not try to unlock a free data item.

Database Management Systems

Two-Phase Locking Techniques: Essential components
 The following code performs the lock operation:

B:if LOCK (X) = 0 (*item is unlocked*)

then LOCK (X)  1 (*lock the item*)
else begin
wait (until lock (X) = 0) and
the lock manager wakes up the transaction);
goto B
end;

Database Management Systems

Two-Phase Locking Techniques: Essential
components
 The following code performs the unlock operation:

LOCK (X)  0 (*unlock the item*)

if any transactions are waiting then
wake up one of the waiting the transactions;

Database Management Systems

 Two-Phase Locking Techniques: Essential components
 The following code performs the read operation:
B: if LOCK (X) = “unlocked” then
begin LOCK (X)  “read-locked”;
no_of_reads (X)  1;
end
else if LOCK (X)  “read-locked” then
no_of_reads (X)  no_of_reads (X) +1
else begin wait (until LOCK (X) = “unlocked” and
the lock manager wakes up the transaction);
go to B
end;

Database Management Systems

 Two-Phase Locking Techniques: Essential components
 The following code performs the write lock operation:
B: if LOCK (X) = “unlocked” then
begin LOCK (X)  “read-locked”;
no_of_reads (X)  1;
end
else if LOCK (X)  “read-locked” then
no_of_reads (X)  no_of_reads (X) +1
else begin wait (until LOCK (X) = “unlocked” and
the lock manager wakes up the transaction);
go to B
end;

Database Management Systems

Two-Phase Locking Techniques: Essential components

The following code performs the unlock operation:
if LOCK (X) = “write-locked” then
begin LOCK (X)  “unlocked”;
wakes up one of the transactions, if any
end
else if LOCK (X)  “read-locked” then
begin
no_of_reads (X)  no_of_reads (X) -1
if no_of_reads (X) = 0 then
begin
LOCK (X) = “unlocked”;
wake up one of the transactions, if any
end
end;

Database Management Systems

 Two-Phase Locking Techniques: Essential components
 Lock conversion
 Lock upgrade: existing read lock to write lock

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

Ti has a write-lock (X) (*no transaction can have any lock on
X*)
convert write-lock (X) to read-lock (X)

Database Management Systems

 Two-Phase Locking Techniques: The algorithm
 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.
 Unlocking (Shrinking) Phase:
 A transaction unlocks its locked data items one at a time.

 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.

Database Management Systems

Two-Phase Locking Techniques: The algorithm

T1 T2 Result
read_lock (Y); read_lock (X); Initial values: X=20; Y=30
read_item (Y); read_item (X); Result of serial execution
unlock (Y); unlock (X); T1 followed by T2
write_lock (X); Write_lock (Y); X=50, Y=80.
read_item (X); read_item (Y); Result of serial execution
X:=X+Y; Y:=X+Y; T2 followed by T1
write_item (X); write_item (Y); X=70, Y=50
unlock (X); unlock (Y);

Database Management Systems

Two-Phase Locking Techniques: The algorithm

T1 T2 Result
read_lock (Y); X=50; Y=50
read_item (Y); Nonserializable because it.
unlock (Y); violated two-phase policy.
read_lock (X);
read_item (X);
unlock (X);
Time write_lock (Y);
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);

Database Management Systems

 Two-Phase Locking Techniques: The algorithm

T’1 T’2
read_lock (Y); read_lock (X); T1 and T2 follow two-phase
read_item (Y); read_item (X); policy but they are subject to
write_lock (X); Write_lock (Y); deadlock, which must be
unlock (Y); unlock (X); dealt with.
read_item (X); read_item (Y);
X:=X+Y; Y:=X+Y;
write_item (X); write_item (Y);
unlock (X); unlock (Y);

Database Management Systems

 Two-Phase Locking Techniques: The algorithm
 Two-phase policy generates two locking algorithms

(a) Basic

(b) Conservative
 Conservative:

Prevents deadlock by locking all desired data items before
transaction begins execution.
 Basic:

Transaction locks data items incrementally. This may cause
deadlock which is dealt with.
 Strict:

A more stricter version of Basic algorithm where unlocking is
performed after a transaction terminates (commits or aborts and
rolled-back). This is the most commonly used two-phase locking
algorithm.

Database Management Systems

 Dealing with Deadlock and Starvation
 Deadlock
T’1 T’2
read_lock (Y); T1 and T2 did follow two-phase
read_item (Y); policy but they are deadlock
read_lock (X);
read_item (Y);
write_lock (X);
(waits for X) write_lock (Y);
(waits for Y)

 Deadlock (T’1 and T’2)

Database Management Systems

 Dealing with Deadlock and Starvation
 Deadlock-Example 2

T1 T2
X(A)
W(A)
X(B)
W(B)
X(A)
W(A)
X(B)
W(B)

Database Management Systems

Deadlock Prevention

 Priority to each transaction is assigned.

 Ts are allowed to wait depending upon their
priorities
 Assigning the priority means associating a
unique value, called timestamp, to each
transaction
 Lower timestamp - higher priority
 Higher timestamp - lower priority

Database Management Systems

 Methods
Wait-die:
(a) If Ti < Tj (Ti has a higher priority than Tj), then Ti is allowed
to wait. Otherwise, Ti is aborted and rolled back.
(b) Lower priority transactions can never wait for higher
priority transactions.
(c) It is nonpreemptive meaning only a transaction
requesting a lock can be aborted.

Wound-wait:
(a) If Ti < Tj (Ti has a higher priority than Tj), then abort Tj.
Otherwise, Ti is allowed to wait.
(b) Higher priority transactions can never wait for lower priority
transactions. Or, higher priority ones wounds (forces
rollback) of lower priority ones.
(c) It is preemptive.
Database Management Systems
  Wait-die

T2 holds a lock T1 holds a lock

A A

T1 requests a lock T1 can wait T2 requests a lock T2 is aborted

 Wound-wait

T2 holds a lock T1 holds a lock

A A

T1 requests a lock Abort T2 T2 requests a lock T2 can wait

Database Management Systems

Wound-wait

Database Management Systems

Deadlock Detection
 To detect deadlocks we use a waits-for graph.
Step-1: Draw a vertex for each transaction in the
schedule
Step-2: An edge Ti  Tj is added to the
graph if
and only if Ti is waiting for Tj
Step-3: An edge Ti  Tj is removed from the
graph if Tj has
released the lock
Step-4: If the graph at any point of time has
cycles, it
implies a deadlock
Database Management Systems
Example-1

T1 T2 T3 T4
T1 T2
X(A)

X(A)

X(A)
T3 T4
X(B)

X(B)

Database Management Systems

Example 2

T1 T2
X(A) T1 T2
W(A)
X(B)
W(B)
X(A)
W(A)
X(B)
W(B)

Database Management Systems

 Dealing with Deadlock and Starvation
 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.
 In Wound-Wait scheme a younger transaction may always
be wounded (aborted) by a long running older transaction
which may create starvation.

Database Management Systems

 Timestamp based concurrency control algorithm
 Timestamp

 A monotonically increasing variable (integer)

indicating the age of an operation or a transaction.
A larger timestamp value indicates a more recent
event or operation.
 Timestamp based algorithm uses timestamp to
serialize the execution of concurrent transactions.

Database Management Systems

Timestamp based concurrency control algorithm
 Basic Timestamp Ordering
 1. Transaction T issues a write_item(X) operation:

If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then an
younger transaction has already read the data item so abort
and roll-back T and reject the operation.

If the condition in part (a) does not exist, then execute
write_item(X) of T and set write_TS(X) to TS(T).
 2. Transaction T issues a read_item(X) operation:

If write_TS(X) > TS(T), then an younger transaction has
already written to the data item so abort and roll-back T and
reject the operation.

If write_TS(X)  TS(T), then execute read_item(X) of T and
set read_TS(X) to the larger of TS(T) and the current
read_TS(X).

Database Management Systems

Timestamp based concurrency control algorithm
 Strict Timestamp Ordering

 1. Transaction T issues a write_item(X) operation:


If TS(T) > read_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).
 2. Transaction T issues a read_item(X) operation:

If TS(T) > write_TS(X), then delay T until the
transaction T’ that wrote or read X has terminated
(committed or aborted).

Database Management Systems

Timestamp based concurrency control algorithm
 Thomas’s Write Rule

 If read_TS(X) > TS(T) then abort and roll-back T

and reject the operation.
 If write_TS(X) > TS(T), then just ignore the write
operation and continue execution. This is because
the most recent writes counts in case of two
consecutive writes.
 If the conditions given in 1 and 2 above do not
occur, then execute write_item(X) of T and set
write_TS(X) to TS(T).

Database Management Systems

 Databases Recovery

Database Management Systems

Purpose of Database Recovery
 To bring the database into the last consistent state,

which existed prior to the failure.

 To preserve transaction properties (Atomicity,

Consistency, Isolation and Durability).

Example:
 If the system crashes before a fund transfer

transaction completes its execution, then either one or

both accounts may have incorrect value. Thus, the
database must be restored to the state before the
transaction modified any of the accounts.

Database Management Systems

Types of Failure
 The database may become unavailable for use
due to

Transaction failure: Transactions may fail
because of incorrect input, deadlock, incorrect
synchronization.

System failure: System may fail because of
addressing error, application error, operating system
fault, RAM failure, etc.

Media failure: Disk head crash, power disruption,
etc.

Database Management Systems

Transaction Log

For recovery from any type of failure data values prior to
modification (BFIM - BeFore Image) and the new value after
modification (AFIM – AFter Image) are required.

These values and other information is stored in a sequential
file called Transaction log. A sample log is given below.
Back P and Next P point to the previous and next log
records of the same transaction.
T ID Back P Next P Operation Data item BFIM AFIM
T1 0 1 Begin
T1 1 4 Write X X = 100 X = 200
T2 0 8 Begin
T1 2 5 W Y Y = 50 Y = 100
T1 4 7 R M M = 200 M = 200
T3 0 9 R N N = 400 N = 400
T1 5 nil End

Database Management Systems

Data Update
 Immediate Update: As soon as a data item is modified in
cache, the disk copy is updated.
 Deferred Update: All modified data items in the cache is
written either after a transaction ends its execution or after a
fixed number of transactions have completed their
execution.
 Shadow update: The modified version of a data item does
not overwrite its disk copy but is written at a separate disk
location.
 In-place update: The disk version of the data item is
overwritten by the cache version.

Database Management Systems

Data Caching
 Data items to be modified are first stored into
database cache by the Cache Manager (CM) and
after modification they are flushed (written) to the
disk.
 The flushing is controlled by Modified and Pin-
Unpin bits.

Pin-Unpin: Instructs the operating system not to
flush the data item.

Modified: Indicates the AFIM of the data item.

Database Management Systems

Transaction Roll-back (Undo) and Roll-Forward
(Redo)
 To maintain atomicity, a transaction’s operations
are redone or undone.

Undo: Restore all BFIMs on to disk (Remove all
AFIMs).

Redo: Restore all AFIMs on to disk.
 Database recovery is achieved either by
performing only Undos or only Redos or by a
combination of the two. These operations are
recorded in the log as they happen.

Database Management Systems

Recovery Methods

 Undo (Backup Recovery)

Undo
Database Database
With changes Without
changes
Before
Image

 Redo (Forward Recovery)

Redo
Database Database
Without With changes
changes
After
Image

Database Management Systems

Database Management Systems
Database Management Systems
Roll-back: One execution of T1, T2 and T3 as recorded in
the log.

Database Management Systems

Write-Ahead Logging
 When in-place update (immediate or deferred) is used

then log is necessary for recovery and it must be available

to recovery manager. This is achieved by Write-Ahead
Logging (WAL) protocol. WAL states that
 For Undo: Before a data item’s AFIM is flushed to the
database disk (overwriting the BFIM) its BFIM must be
written to the log and the log must be saved on a stable
store (log disk).
 For Redo: Before a transaction executes its commit
operation, all its AFIMs must be written to the log and the
log must be saved on a stable store.

Database Management Systems

Checkpointing
 Time to time (randomly or under some criteria) the
database flushes its buffer to database disk to minimize
the task of recovery. The following steps defines a
checkpoint operation:
1. Suspend execution of transactions temporarily.
2. Force write modified buffer data to disk.
3. Write a [checkpoint] record to the log, save the log to disk.
4. Resume normal transaction execution.
 During recovery redo or undo is required to transactions
appearing after [checkpoint] record.

Database Management Systems

 Steal/No-Steal and Force/No-Force

Possible ways for flushing database cache to database
disk:
1. Steal: Cache can be flushed before transaction commits.
2. No-Steal: Cache cannot be flushed before transaction
commit.
3. Force: Cache is immediately flushed (forced) to disk.
4. No-Force: Cache is deferred until transaction commits

These give rise to four different ways for handling
recovery:

Steal/No-Force (Undo/Redo)

Steal/Force (Undo/No-redo)

No-Steal/No-Force (Redo/No-undo)

No-Steal/Force (No-undo/No-redo)

Database Management Systems

 Recovery Scheme
 Deferred Update (No Undo/Redo)

 The data update goes as follows:

 A set of transactions records their updates in the
log.
 At commit point under WAL scheme these updates
are saved on database disk.
 After reboot from a failure the log is used to redo
all the transactions affected by this failure. No
undo is required because no AFIM is flushed to the
disk before a transaction commits.

Database Management Systems

 Deferred Update in a single-user system
There is no concurrent data sharing in a single user
system. The data update goes as follows:
 A set of transactions records their updates in the log.
 At commit point under WAL scheme these updates are
saved on database disk.
 After reboot from a failure the log is used to redo all the
transactions affected by this failure. No undo is required
because no AFIM is flushed to the disk before a
transaction commits.

Database Management Systems

Database Management Systems
Deferred Update with concurrent users
 This environment requires some concurrency control

mechanism to guarantee isolation property of

transactions. In a system recovery transactions which
were recorded in the log after the last checkpoint were
redone. The recovery manager may scan some of the
transactions recorded before the checkpoint to get the
AFIMs.

Database Management Systems

Database Management Systems
Deferred Update with concurrent users
 Two tables are required for implementing this protocol:

Active table: All active transactions are entered in this
table.

Commit table: Transactions to be committed are entered in
this table.

 During recovery, all transactions of the commit table are

redone and all transactions of active tables are ignored
since none of their AFIMs reached the database. It is
possible that a commit table transaction may be redone
twice but this does not create any inconsistency because
of a redone is “idempotent”, that is, one redone for an
AFIM is equivalent to multiple redone for the same AFIM.

Database Management Systems

Recovery Techniques Based on Immediate Update
 Undo/No-redo Algorithm

 In this algorithm AFIMs of a transaction are flushed

to the database disk under WAL before it commits.
 For this reason the recovery manager undoes all
transactions during recovery.
 No transaction is redone.
 It is possible that a transaction might have
completed execution and ready to commit but this
transaction is also undone.

Database Management Systems

 Recovery Techniques Based on Immediate Update
 Undo/Redo Algorithm (Single-user environment)


Recovery schemes of this category apply undo and
also redo for recovery.

In a single-user environment no concurrency control
is required but a log is maintained under WAL.

Note that at any time there will be one transaction in
the system and it will be either in the commit table
or in the active table.

The recovery manager performs:
 Undo of a transaction if it is in the active table.
 Redo of a transaction if it is in the commit table.

Database Management Systems

Recovery Techniques Based on Immediate Update
 Undo/Redo Algorithm (Concurrent execution)

 Recovery schemes of this category applies undo and also

redo to recover the database from failure.

 In concurrent execution environment a concurrency
control is required and log is maintained under WAL.
 Commit table records transactions to be committed and

active table records active transactions. To minimize the

work of the recovery manager checkpointing is used.
 The recovery performs:

 Undo of a transaction if it is in the active table.

 Redo of a transaction if it is in the commit table.

Database Management Systems

Shadow Paging
 The AFIM does not overwrite its BFIM but recorded at

another place on the disk. Thus, at any time a data item

has AFIM and BFIM (Shadow copy of the data item) at
two different places on the disk.

X Y
X' Y'

Database

X and Y: Shadow copies of data items

X' and Y': Current copies of data items
Database Management Systems
No-Undo/No-Redo Protocol (Shadow Paging)

Page 4
(old)
1 
Page 1  1
2 
 2
3 
Page 3  3
4 
 4
5 
Page 2  5
Current directory
(new) Shadow directory
(updating pages 2 & 4)

Page 4
(new)

Page 2
(old)
Database Management Systems
Shadow Paging
 To manage access of data items by concurrent

transactions two directories (current and shadow) are

used.

The directory arrangement is illustrated below. Here a page
is a data item.

Database Management Systems