COURSE NAME: DBMS

COURSE CODE:23AD2102A
TOPIC:
CONCURRENCY CONTROL
TECHNIQUES

Session - 06

1
 AIM OF THE SESSION
To familiarize students with the basic concepts of Transaction Management
To aware the students how to define the concurrency control techniques & Mechanisms.
To grasp the students about the concept of Recovery Management.

INSTRUCTIONAL OBJECTIVES

This Session is designed to get the enough knowledge about the Shadowing Technique & Recovery

LEARNING OUTCOMES

At the end of this session, you should be able to define the mechanisms of concurrency control with examples.
BASIC CONCEPTS

• There are several concurrency control techniques that are used to

ensure isolation property of concurrent executing transactions.
• Most of these techniques ensure serializability of schedules.
• Some techniques use the concept of locking data items to prevent
multiple transactions from accessing the items concurrently.
• Other techniques use the concept of timestamps.
• A timestamp is a unique identifier for each transaction, generated by
the system. Timestamps values are generated in the same order as the
transaction start times.
LOCKING TECHNIQUES FOR CONCURRENCY
CONTROL

• The concept of locking data items is one of the main techniques used for controlling
the concurrent execution of transactions.
• A lock is a variable associated with a data item in the database. Generally there is a
lock for each data item in the database.
• A lock describes the status of the data item with respect to possible operations that
can be applied to that item. It is used for synchronizing the access by concurrent
transactions to the database items.
• A transaction locks an object before using it.
• When an object is locked by another transaction, the requesting transaction must wait.
TYPES OF LOCKS

• Binary locks have two possible states:

1. locked (lock_item(X) operation) and
2. unlocked (unlock_item(X) operation

• If the simple binary locking is used then 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).
• 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 hold the
lock on item X.
 TYPES OF LOCKS(CONT..)

• Shared/Exclusive(or Read/Write) locks allow

concurrent access to the same item by several
transactions. Three possible states exists in this
type of locking:
1. read locked or shared locked (other
transactions are allowed to read the item)
2. write locked or exclusive locked (a single
transaction exclusively holds the lock on the
item) and
3. unlocked.
TYPES OF LOCKS(CONT..)

• When shared/exclusive locking scheme is used then the system must enforce the
following rules:
• A transaction T must issue the operation read_lock(X) or write_lock(X) before any
read_item(X) operation is performed in T.
• A transaction T must issue the operation write_lock(X) before any write_item(X)
operation is performed in T.
• A transaction T must issue the operation unlock(X) after all read_item(X) and
write_item(X) operations are completed in T.
• A transaction T will not issue a read_lock(X) operation if it already holds a read
(shared) lock or a write (exclusive) lock on item X.
• A transaction T will not issue a write_lock(X) operation if it already holds a read
(shared) lock or write (exclusive) lock on item X.
• A transaction T will not issue an unlock(X) operation unless it already holds a
read (shared) lock or a write (exclusive) lock on item X.

7
LOCKS DON’T GUARANTEE
SERIALISABILITY : LOST UPDATE
T1 T2 X Y

write_lock(X)
read_item(X); 4
X:= X - N; 2
unlock(X)
write_lock(X)
read_item(X); 4
X:= X + M; 7
unlock(X)
write_lock(X)
write_item(X); 2
unlock(X)
write_lock(Y)
read_item(Y); 8
write_lock(X)
write_item(X); 7
unlock(X)
Y:= Y + N; 10
write_item(Y); 10
unlock(Y)
 LOCKS DON’T GUARANTEE
SERIALISABILITY (CONT..)

X=20, Y=30
T1 T2
read_lock(Y); read_lock(X);
read_item(Y); read_item(X);
unlock(Y); unlock(X);
write_lock(X); write_lock(Y);
read_item(X); read_item(Y);
X:=X+Y; Y:=X+Y;
write_item(X); write_item(Y);
unlock(X); unlock(Y);
________________________________________________________________________

Y is unlocked too early X is unlocked too early

 Schedule 1: T1 followed by T2  X=50, Y=80
 Schedule 2: T2 followed by T1  X=70, Y=50
NON-SERIALISABLE SCHEDULE S THAT
USES LOCKS
X=20Y=30

T1 T2
read_lock(Y);
read_item(Y);
unlock(Y);
read_lock(X);
read_item(X);
unlock(X);
write_lock(Y);
read_item(Y);
Y:=X+Y;
write_item(Y);
unlock(Y);
write_lock(X);
read_item(X);
X:=X+Y; result of S  X=50,
write_item(X); Y=50
unlock(X);
 ENSURING SERIALISABILITY : TWO-PHASE
LOCKING

• In this type of locking, a transaction must follow two phases:

• expanding phase: new locks on items can be acquired but none can
be released
• shrinking phase: existing locks can be released but no new ones
can be acquired

• In two phase locking, it is possible for a transaction to issue a

read_lock(X) and then later onto upgrade the lock by issuing a
write_lock(X) operation. If T is the only transaction holding a read lock
on X at the time it issues the write_lock(X) operation, the lock can be
upgraded: otherwise, the transaction must wait.
ENSURING SERIALISABILITY: TWO-PHASE
LOCKING:EXAMPLE
X=20, Y=30

T1 T2
read_lock(Y); read_lock(X);
read_item(Y); read_item(X);
write_lock(X); write_lock(Y);
unlock(Y); unlock(X);
read_item(X); read_item(Y);
X:=X+Y; Y:=X+Y;
write_item(X); write_item(Y);
unlock(X); unlock(Y);

Slid
LOCKING PROBLEMS: DEADLOCK

• Each of two or more transactions is waiting for the other to

T1 T2
release an item.
read_lock(Y);
read_item(Y);
read_lock(X);
read_item(X);
write_lock(X);
write_lock(Y);

Slid
TYPES OF TWO-PHASING LOCKING

• Basic 2PL
• When a transaction releases a lock, it may not request another lock
• Conservative 2PL or static 2PL
• a transaction locks all the items it accesses before the transaction begins
execution
• pre-declaring read and write sets
• Strict 2PL
• a transaction does not release any of its locks until after it commits or
aborts

Slid
TIMESTAMP BASED CONCURRENCY CONTROL

• Timestamp is a unique identifier created by the DBMS to identify a

transaction.
• Each transaction is issued a timestamp when it enters the system. If an old
transaction Ti has time-stamp TS(Ti), a new transaction Tj is assigned time-
stamp TS(Tj) such that TS(Ti) < TS(Tj).

• In timestamp ordering, the schedule is equivalent to the particular serial

order corresponding to the order of the transaction timestamps unlike lock
based technique where schedule is made serial schedule based on locks.

Slid
TIMESTAMP BASED CONCURRENCY CONTROL
TECHNIQUE
• In this technique each data item X maintains two
timestamp values:
Write_TS(X) is the largest time-stamp of any transaction that
executed write(X) successfully.
Read_TS(X) is the largest time-stamp of any transaction that
executed read(X) successfully
• The timestamp ordering protocol ensures that any conflicting read
and write operations are executed in timestamp order.

Slid
 TIMESTAMP BASED CONCURRENCY CONTROL
TECHNIQUE

• Basic Timestamp Ordering (TO): This concurrency control technique

check whether conflicting operations violate the timestamp ordering in the
following two cases:
• 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 above part does not exist, then execute
write_item(X) of T and set write_TS(X) to TS(T).

Slid
TIMESTAMP BASED CONCURRENCY CONTROL
TECHNIQUE

• 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).

18
 TIMESTAMP BASED CONCURRENCY CONTROL
TECHNIQUE

• Strict Timestamp Ordering: This concurrency control technique check

whether conflicting operations violate the timestamp ordering in the
following two cases:

• 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).
• 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).

Slid
 A partial schedule for several data items for transactions T1 ,
Step 1
T , T3 , T4T,t2T5 with Ttimestamps
T1t12 t3
T t4t1 < t2 <
T t5 t3 < t4 < t5
2 3 4 5 X Y Z
read1(X)
read3(Y)
read2(Y) R W R W R W
write4(Y)
write5(Z) 1 2 4 6 5
read6(Z) t5 t2 t3 t5 t3
read7(Y)
abort
write9(Z)
abort
write(Y)
write(Z)
Now this needs to
be rolled back
LOCKING GRANULARITY

• A database item could be

• a database record
• a field value of a database record
• a disk block
• the whole database
• The granularity can affect the performance of concurrency
control and recovery.

Slid
LOCKING GRANULARITY

• Trade-offs
• coarse granularity
• the larger the data item size, the lower the degree of
concurrency
• fine granularity
• the smaller the data item size, the more locks to be
managed and stored, and the more lock/unlock operations
needed.

22
RECOVERY TECHNIQUES

• Recovery Based on Deferred Update.

• Recovery Techniques Based on Immediate Update.
• Shadow Paging

Slid
RECOVERY BASED ON DEFERRED
UPDATE
• These techniques defer or postpone any actual updates to the database until the
transaction reaches it commit point.
• Following steps followed in this technique:
• Updates recorded in log FAILURE!
• Transaction commit point REDO database from log entries
• Force log to the disk No UNDO necessary because
• Update the database database never altered
• Recovery techniques based on deferred update are therefore known as NO UNDO/REDO
techniques. REDO is needed in case the system fails after a transaction commits but before
all its changes are recorded on disk. In this case, the transaction operations are redone from
the log file.

Slid
RECOVERY TECHNIQUES BASED ON
IMMEDIATE UPDATE
• When a transaction issues an update command, the database can
be updated immediately, without waiting for the transaction to
reach its commit point.
• There are two varieties of this technique:
• UNDO/NO-REDO recovery technique: In this method, all updates by a
transaction must be recorded on disk before the transaction commits, so that
REDO is never needed General case of UNDO/REDO recovery technique.
• UNDO/REDO recovery technique: If the transaction is allowed to commit
before all its changes are written to the database.

Slid
SHADOW PAGING TECHNIQUE

• Data isn’t updated ‘in place’.

• The database is considered to be made up of a number of n
fixed-size disk blocks or pages, for recovery purposes.
• A page table with n entries is constructed where the ith page
page 5

table entry points to the ith database page on disk. page 1

1
• Current page table points to most 2 page 4
3
4
recent current database pages on disk5 page 2
6
page 3

page 6
Slid
SHADOW PAGING TECHNIQUE(CONT..)

• When a transaction begins executing

• the current page table is copied into a shadow page table
• shadow page table is then saved
• shadow page table is never modified during transaction
execution
• writes operations—new copy of database page is created and
current page table entry modified to point to new disk
page/block

Slid
SHADOW PAGING TECHNIQUE(CONT..)
Database data pages (blocks)

Current page table page 5 (old)

(after updating pages Shadow page table
2,6) page 1 (not updated)

page 4 1
1
2 2
page 2 (old) 3
3
4
4
5
5 page 3 6
6

page 6

page 2 (new)

page 5 (new)

Slid
SHADOW PAGING TECHNIQUE(CONT..)

• To recover from a failure

• The state of the database before transaction execution is available through the
shadow page table.
• Free modified pages.
• Discard current page table.
• That state is recovered by reinstating the shadow page table to become the
current page table once more.
• Commiting a transaction
• Discard previous shadow page .
• Free old page tables that it references.

Slid
REFERENCES

• Silberschatz, A., Korth, H. F., & Sudarshan, S. (2010). Database system

concepts. New York: McGraw-Hill.
• Elmasri, R., &Navathe, S. (2010). Fundamentals of database systems.
Pearson Education India.

Slid