Concurrency

Control
Concurrency Control Techniques
• Lock Based Protocols:
• A lock is a mechanism to control concurrent access to a data item
• A Lock is a variable assigned to any data item in order to keep track of the status of that
data item so that isolation and non-interference is ensured during concurrent
transactions.

28-Apr-25 Dept. Of I&CT 2

Concurrency Control Techniques: Lock Based Protocols:
1. Two Phase Locking Protocol
• Instead of locking the entire database, a transaction could, instead, lock only those data items that it
accesses
• The transaction must hold locks long enough to ensure serializability, but for a period short enough not to
harm performance excessively.
2. Timestamp Protocol
• The read timestamp of a data item holds the largest (most recent) timestamp of those transactions that
read the data item
• The write timestamp of a data item holds the timestamp of the transaction that write the current value of
the data item
3. Multiversion Protocol – Snapshot Isolation
• Each transaction is given its own version, or snapshot, of the database when it begins.
• It reads data from this private version and is thus isolated from the updates made by other transactions
• If the transaction updates the DB, that update appears only in its own version, not in the actual DB itself.

28-Apr-25 Dept. Of I&CT 3

Types of Locks and System Lock Tables

• Binary Locks: A binary lock can have two

states or values: locked and unlocked.
• If the value of the lock on X is 1, item X
cannot be accessed by a DB operation that
requests the item
• If the value of the lock on X is 0, the item
can be accessed when requested, and the
lock value is changed to 1.
• The current value (or state) of the lock
associated with item X as lock(X).

28-Apr-25 Dept. Of I&CT 4

Operations of Binary Locks

• Two operations:
• lock_item,
• unlock_item
• Binary lock enforces
mutual exclusion on
the data item:
Indivisible units or
critical section or no
interleaving

28-Apr-25 Dept. Of I&CT 5

Binary Locks
• Lock Table: Maintains the records for items that are currently locked in a
which could be organized as a hash file on the item name

• Lock table record: Three fields

<data_item_name, LOCK, Locking_transaction>

• Items not in the lock table are considered to be unlocked

• The DBMS has a lock manager subsystem to keep track of and control
access to locks

28-Apr-25 Dept. Of I&CT 6

Rules for Binary Locking
• A transaction T must issue the operations 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

28-Apr-25 Dept. Of I&CT 7

Advantages of Binary Locking
• They are simple to implement since they are effectively mutually exclusive
and establish isolation perfectly.
• Binary Locks demand less from the system since the system must only keep a
record of the locked items.

Disadvantages of Binary Locking

• Binary locks are highly restrictive because at most one transaction can hold
the lock on a given item.
• We should allow several transactions to access the same item X if they access
X for reading purpose only
28-Apr-25 Dept. Of I&CT 8
Shared/Exclusive (Read/Write) Lock
• Multiple-mode lock / Shared/Exclusive or Read/Write locks
• Three locking operations: read_lock(X), write_lock(X), and unlock(X)
• A read-locked item is called share-locked because other transactions are allowed to
read the item
• write-locked item is called exclusive locked because single transaction exclusively
holds the lock for the item
• Locking table record :
<data_item_name, LOCK, No-of-reads, Locking_transaction>

28-Apr-25 Dept. Of I&CT 9

Shared/Exclusive (Read/Write) Lock

28-Apr-25 Dept. Of I&CT 10

Shared/Exclusive (Read/Write) Lock

28-Apr-25 Dept. Of I&CT 11

Rules for Shared/Exclusive Locks
• 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 operations unlock(X) after all read_item(X) and write_item(X)
operations are completed in T
• A transaction T will not issue read_lock(X) operation if it already holds a read (shared) lock
or a write lock (exclusive) on item X – can be downgraded

• A transaction T will not issue a write_lock(X) operation of it already holds a read (shared)
lock or write (exclusive) lock on item X – can be upgraded
• A transaction T will not issue an unlock(X) operation unless it already holds a read lock or a
write lock on item X
28-Apr-25 Dept. Of I&CT 12
 • Example of a transaction performing locking:
T2: lock-S(A);
read (A);
unlock(A);

lock-S(B);
read (B);
unlock(B);
display(A+B)
• Locking as above is not sufficient to guarantee serializability

28-Apr-25 Dept. of I&CT 13

28-Apr-25 Dept. of I&CT 14
Two-Phase Locking Protocol – Basic 2PL
• A transaction is said to follow two-phase locking protocol if all the locking
operations precede the first unlock operation in the transaction
• Two phases: Expanding or Growing (First) Phase and Shrinking (Second) Phase
• Expanding Phase: During which new locks on items can be acquired but none can
be released
• Shrinking Phase: During which existing locks can be released but no new locks
can be acquired
• If the lock conversion is allowed, then upgrading of locks must be done in the
expanding phase and downgrading of locks must be done in the shrinking phase

28-Apr-25 Dept. Of I&CT 15

Two-Phase Locking Protocol – Basic 2PL

28-Apr-25 Dept. Of I&CT 16

Variations of 2PL
• Conservative 2PL or Static 2PL: requires a transaction to lock all the items it accesses before the
transaction begins its execution by pre-declaring it’s read-set and write-set
• If any of the predeclared items needed cannot be locked, the transaction does not lock any
item, instead it waits until all the items are available for locking
• Deadlock-free protocol but difficult to use in practice
• Strict 2PL: A transaction T does not release any of its exclusive (write) locks until after it commits
or aborts
• Hence, no other transaction can read or write an item that is written by T unless T has
committed leading to a strict schedule for recoverability
• Not deadlock free
• Rigorous 2PL: A transaction T does not release any of its locks (shared/exclusive) until after it
commits or aborts
 Easy to implement
 Use of locks leads to two additional problems: deadlock and starvation
28-Apr-25 Dept. Of I&CT 17
Variations of 2PL

• The conservative 2PL must lock all its items before it starts, so once
the transaction starts it is in its shrinking phase;
• The rigorous 2PL does not unlock any of its items until after it
terminates (by committing or aborting), so the transaction is in its
expanding phase until it ends

28-Apr-25 Dept. Of I&CT 18

Deadlocks and Starvation
• Deadlock occurs when each transaction T in set of two or more transactions
are waiting for some item that is locked by some other transaction T’ in the set
• Each transaction in the set is in the waiting queue, waiting for one of the other
transaction in the set to release the lock on an item.
• But because the other transaction is also waiting, it will never release the lock

28-Apr-25 Dept. Of I&CT 19

Deadlock Prevention Protocols
• One deadlock prevention protocol is Conservative 2PL, requires that every
transaction lock all items it needs in advance; if any of the items cannot be
obtained, none of the items are locked.
• Rather, the transaction waits and then tries again to lock the items it needs

• A second protocol, involves ordering all the items in the DB and making sure
that a transaction that needs several items will lock them according to that
order.
• This requires that the programmer (or the system) is aware of the chosen order of items

• Third method is using the Transaction Timestamp, TS(T) which is the

unique identifier assigned to each transaction
28-Apr-25 Dept. Of I&CT 20
Deadlock Prevention Protocols
• 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).
• Older Transaction – Started First(Smaller TS value), Younger – Started Later
• Two schemes – wait-die and wound-wait

28-Apr-25 Dept. Of I&CT 21

Deadlock Prevention Protocols
• If transaction Ti tries to lock and item X but is not able to because X is locked by some
other transaction Tj with a conflicting lock, the rules followed by timestamp schemes that
prevent deadlock are:
1. Wait-die: If TS(Ti)<TS(Tj), then (Ti is older than Tj), Ti is allowed to wait; otherwise
(Ti is younger than Tj) abort Ti (Ti dies) and restart it later with the same timestamp
 An older transaction is allowed to wait for a younger transaction, whereas a younger
transaction requesting an item held by an older transaction is aborted and restarted.
2. Wound-wait: If TS(Ti)<TS(Tj), then (Ti is older than Tj) abort Tj (Ti wounds Tj) and
restart it later with the same timestamp; otherwise (Ti is younger than Tj) Ti is allowed to
wait
 A younger transaction is allowed to wait for an older one, whereas an older
transaction requesting an item held by a younger one preempts it by aborting it

28-Apr-25 Dept. Of I&CT 22

Deadlock Prevention Protocols
• These two techniques are deadlock-free
• In wait-die, transactions only wait for younger transactions, so no cycle is created.
• In wound-wait, transactions only wait for older transactions, so no cycle is created
• Both techniques may cause some transactions to be aborted and restarted
needlessly, even though those transactions may never actually cause a
deadlock.

28-Apr-25 Dept. of I&CT 23

Deadlock Prevention Protocols
3. No waiting: If a transaction is unable to obtain a lock, it is immediately
aborted and then restarted after a certain time delay without checking whether
a deadlock will actually occur or not
 No transaction ever waits, so no deadlock will occur. However, this
scheme can cause transactions to abort and restart needlessly.
4. Cautious Waiting: Transaction Ti tries to lock an item X but is not able to
do so because X is locked by some other transaction Tj with a conflicting lock
 If Tj is not blocked (not waiting for some other locked item), then Ti is
blocked and allowed to wait; otherwise abort Ti.
Cautious waiting is deadlock-free, because no transaction will ever wait for
another blocked transaction
28-Apr-25 Dept. Of I&CT 24
Deadlock Detection
• Deadlock Detection is where the system checks if a state of deadlock actually
exists
• Wait-for-graph is used for deadlock detection
• One node is created in the wait-for-graph for each transaction that is currently
executing
• Whenever a transaction Ti is waiting to lock an item X that is currently locked
by a transaction Tj, a directed edge (TiTj) is created in the wait-for-graph
• When Tj releases the lock(s) on the item(s) that Ti was waiting for, the
directed edge is dropped from the wait-for-graph
• We have a state of deadlock if and only if the wait-for-graph has a cycle

28-Apr-25 Dept. Of I&CT 25

Deadlock Detection
• One Problem: When to check for deadlock?
• Every time a transaction is added? – Overhead
• Victim Selection: Choosing which transactions to abort during deadlocks
• Timeouts: practical because of its low overhead and simplicity
• Starvation: 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 other
Solution: First come first serve

28-Apr-25 Dept. Of I&CT 26

Timestamp Ordering – Concurrency Control
• A timestamp is a unique identifier created by the DBMS to identify a transaction

• A schedule in which the transactions participate is serializable, and the only

equivalent serial schedule permitted has the transactions on order of their
timestamp values and this is called timestamp ordering (TO)

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

corresponding to the order of the transaction timestamps

• The algorithm must ensure that, for each item accessed by the conflicting
operations in the schedule, the order in which the item is accessed does not violate
the timestamp order

28-Apr-25 Dept. Of I&CT 27

Timestamp Ordering – Concurrency Control
• To do this, the algorithm associates with each database item X two timestamp
(TS) values:
• read_TS(X): The read timestamp of item X is the largest timestamp among all the
timestamps of the transactions that have successfully read item X – i.e., read_TS(X) =
TS(T), where T is the youngest transaction that has read X successfully.

• write_TS(X): The write timestamp of item X is the largest of all the timestamps of
transactions that have successfully written item X – i.e., write_TS(X) = TS(X), where
T is the youngest transaction that has written X successfully.

28-Apr-25 Dept. Of I&CT 28

Basic Timestamp Ordering
• Whenever some transaction T tries to issue a read_item(X) or a write_item(X)
operation, the basic TO algorithm compares the timestamp of T with read_TS(X)
and write_TS(X) to ensure that the TS order of transaction execution is not
violated.
• If this order is violated, then transaction T is aborted and resubmitted to the system
as a new transaction with a new timestamp
• If T is aborted and rolled back, any transaction T1 that may have used a value
written by T must also be rolled back.
• Similarly, any transaction T2 that may have used a value written by T1 must also be
rolled back and so on.
• The effect is called cascading rollback.

28-Apr-25 Dept. Of I&CT 29

Basic Timestamp Ordering
• The concurrency control algorithm must check whether conflicting operations violate
the timestamp ordering in the following two cases:
 Whenever a transaction T issues a write_item(X) operation, the following is
checked:
 If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then abort and rollback T
and reject the operation
 This must be done because, some younger transaction with a timestamp
greater than TS(T) – and hence after T in the TO – has already read or
written the value of item X before T had a chance to write X, thus violating
the TO
 If the condition in part (a) does not occur, then execute the write_item
operation of T and set write_TS(X) to TS(T)
28-Apr-25 Dept. Of I&CT 30
Basic Timestamp Ordering
 Whenever a transaction T issues a read_item(X) operation, the following is
checked.
 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) – and hence after T in the timestamp
ordering – has already written the value of item X before T had a chance
to read X.
 If write_TS(X) <= TS(T), then execute the read_item(X) operation of T
and set read_TS(X) to the larger of TS(T) and the current read_TS(X)

28-Apr-25 Dept. Of I&CT 31

Basic Timestamp Ordering
• Whenever the basic TO algorithm detects two conflicting operations that
occur in the incorrect order, it rejects the later of the two operations by
aborting the transaction that issued it
• The schedules produced by basic TO are hence guaranteed to be conflict
serializable, like the 2PL protocol

28-Apr-25 Dept. Of I&CT 32

Strict Timestamp Ordering
• A variation of basic TO is called strict TO ensures that the schedules are both
strict (for easy recoverability) and (conflict) serializable
• A transaction T that issues a read_item(X) or write_item(X) such that TS(T) >
write_TS(X) has its read or write operation delayed until the transaction T’
that wrote the value of X (hence TS(T’)=write_TS(X)) has committed or
aborted
• It is necessary for locking of an item X that has been written by transaction T’
until T’ is either committed or aborted
• This algorithm does not cause deadlock, since T waits for T’ only if TS(T) >
TS(T’)

28-Apr-25 Dept. Of I&CT 33

Validation Based Protocol
• The validation protocol requires that each transaction Ti executes in two or
three different phases in its lifetime, depending on whether it is read-only or an
update transaction
 Read-Phase: During this phase, the system executes transaction Ti
- It reads the values of the various data items and stores them in
variables local to Ti
- It performs all write operations on temporary local variables,
without updates of the actual DB

28-Apr-25 Dept. Of I&CT 34

Validation Based Protocol
Validation phase: The validation test is applied to transaction Ti.
- This determines whether Ti is allowed to proceed to the write phase
without causing a violation of serializability.
- If a transaction fails the validation test, the system aborts the transaction
 Write phase: If the validation test succeeds for transaction Ti, the temporary
local variables that hold the results of any write operations performed by Ti
are copied to the database.
- Read-only transactions omit this phase

28-Apr-25 Dept. of I&CT 35

Validation Based Protocol
• To perform the validation test, we need to know when the various phases of
transactions took place
• Start(Ti), the time when Ti started its execution.

• Validation(Ti ), the time when Ti finished its read phase and started its validation phase.

• Finish(Ti), the time when Ti finished its write phase

28-Apr-25 Dept. of I&CT 36

Validation Based Protocol
• The validation test for transaction Ti requires that, for all transactions Tk with
TS(Tk ) < TS(Ti ), one of the following two conditions must hold:
• Finish(Tk ) < Start(Ti ). Since Tk completes its execution before Ti starts, the
serializability order is indeed maintained

• The set of data items written by Tk does not intersect with the set of data items read by
Ti, and Tk completes its write phase before Ti starts its validation phase (Start(Ti ) <
Finish(Tk ) < Validation(Ti )).

28-Apr-25 Dept. of I&CT 37