Database

Administration and
Management
Course Instructor: Ms. Ameena Saeed / Dr. Muhammad Asif
Lecture: Concurrency Control and Deadlocks
Agenda
• Locks are used as a means of synchronizing the access by concurrent
transactions to the database items.
• Then we will discuss the nature and types of locks.
• Then we will study protocols that use locking to guarantee
serializability of transaction schedules.
• In the last we will discuss two problems associated with the use of
locks. Deadlock and starvation and show how these problems are
handled in concurrency control protocols.
Introduction
• Concurrency Control: Managing multiple transactions simultaneously
while ensuring data integrity.
• Deadlocks: A state in which two or more transactions are waiting
indefinitely for each other to release locks.
Concurrency control is essential in databases to allow multiple
transactions to execute simultaneously without causing inconsistencies.
However, it can lead to deadlocks, where two or more transactions are
unable to proceed because each is waiting for the other to release
locks.
• The goal is to Ensure data integrity and consistency by managing
simultaneous transactions effectively.
Types of Locks
Locks are used to ensure that transactions do not interfere with each
other in conflicting ways. There are two main types of locks:
1. Shared Lock (S Lock)
Allows multiple transactions to read the same data at the same time
but prevents any of them from modifying it.
2. Exclusive Lock (X Lock)
Only one transaction can write to the data at a time. While an exclusive
lock is held, no other transaction can read or write the data.
Example:
Imagine two transactions trying to access a bank account balance:
• Transaction A wants to read the balance (shared lock).
• Transaction B wants to update the balance (exclusive lock).
Query:
-- Transaction A wants to read (shared lock)
SELECT balance FROM Accounts WHERE account_id = 'A';

-- Transaction B wants to update (exclusive lock)

UPDATE Accounts SET balance = balance + 500 WHERE account_id = 'A';
-- Transaction A's read will be blocked until B finishes.
Lock-compatibility Matrix
Example
• Transaction A holds a shared lock on a record.
• Transaction B can also acquire a shared lock (both can read the data).
• However, if Transaction B requests an exclusive lock, it will be blocked
until Transaction A releases the shared lock.
Query
-- Transaction A (Shared Lock)
BEGIN TRANSACTION;
SELECT * FROM Employees WHERE emp_id = 1; -- Shared lock applied

-- Transaction B (Shared Lock allowed)

SELECT * FROM Employees WHERE emp_id = 1; -- Allowed, as shared locks
are compatible.

-- Transaction B (Exclusive Lock blocked)

UPDATE Employees SET salary = salary + 1000 WHERE emp_id = 1; -- Blocked
until Transaction A releases the shared lock.
The Two-Phase Locking Protocol
(2PL)
• The Two-Phase Locking Protocol (2PL) ensures that transactions
follow a strict order for acquiring and releasing locks to maintain
serializability and avoid concurrency issues.
• A transaction is said to follow the two-phase locking protocol if all
locking operations (read_lock, write_lock) precede the first unlock
operation in the transaction.
• Such a transaction can be divided into two phases: an expanding or
growing (first) phase and a shrink phase.
Cont…
Two Phases:
• Growing Phase:
• A transaction acquires locks as needed but cannot release any locks.
• Shrinking Phase:
• The transaction releases locks but cannot acquire new ones.

By following this approach, 2PL guarantees that once a transaction releases a

lock, it will not request any new locks, preventing deadlocks and ensuring safe,
serializable transactions.
Lock Conversions
Lock conversion allows a transaction to upgrade or downgrade its lock
based on its needs. For example, a transaction might initially acquire a
shared lock and then convert it to an exclusive lock if it needs to update
the data.

Types of Conversions:
• Shared to Exclusive: A shared lock (read) can be upgraded to an
exclusive lock (write) if the transaction needs to modify the data.
• Exclusive to Shared: Rare, but in some cases, after a modification, the
transaction may downgrade the lock to shared for read-only purposes.
Lock Upgrading During Two-Phase Locking
(2PL)
In the two-phase locking protocol, once the transaction enters the
shrinking phase, it can only release locks and cannot acquire new ones.
But lock upgrading is still possible as long as the transaction is in the
growing phase.
1. Lock Phases in 2PL:
• Growing Phase:In this phase, a transaction can acquire new locks or
upgrade existing locks. The key is that the transaction hasn't yet started
to release any locks.
• Lock upgrading (from a shared lock to an exclusive lock) is allowed
because it’s considered part of the growing process — the transaction is
increasing its level of control over the data.
Cont…
• Shrinking Phase:
Once the transaction starts to release locks, it enters the shrinking
phase. At this point, no new locks can be acquired, and no upgrades
are allowed. The transaction can only downgrade or release locks from
here.
Lock Upgrade Example
Step 1: Transaction A Acquires a Shared Lock (Growing Phase)
• Transaction A begins by reading data, and to ensure that no other
transaction can modify this data while it’s being read, the DBMS applies
a shared lock on that data.
• A shared lock allows Transaction A to read the data but prevents any other
transaction from modifying it (other transactions can still read it, though).
Query:
-- Transaction A reads data (Shared Lock applied)
BEGIN TRANSACTION;
SELECT balance FROM Accounts WHERE account_id = 1; -- Shared lock applied on
account_id = 1
Cont…
Step 2: Transaction A Decides to Modify the Data (Upgrading to
Exclusive Lock)
• After reading the data, Transaction A decides it needs to modify the
same data (e.g., update the balance in the account).
• Since modifying data requires exclusive control over it, Transaction A needs to
upgrade the shared lock to an exclusive lock.
• This upgrade is allowed because Transaction A is still in the growing phase (it
hasn’t released any locks yet).
Query:
-- Transaction A upgrades the shared lock to an exclusive lock to modify the data
UPDATE Accounts SET balance = balance - 100 WHERE account_id = 1; -- Shared lock
upgraded to exclusive lock
Cont…
Step 3: Transition to Shrinking Phase
• After modifying the data, once Transaction A starts releasing locks
(such as when it commits or rolls back), it enters the shrinking phase.
• In the shrinking phase, no new locks or upgrades are allowed — only
releasing locks is permitted.

Query:
-- Transaction A commits and releases locks
COMMIT; -- Exclusive lock released, transaction completed
Practice Task: Simulating Shared
and Exclusive Locks
1. Create a table called Accounts with two columns: account_id
(primary key) and balance.
2. Open two separate sessions (simulating two concurrent
transactions: Transaction A and Transaction B).
3. Start a transaction A and acquire a shared lock.
4. In Transaction B:
• Try to acquire a shared lock.
• Then, try to acquire an exclusive lock.
Solution
Query:
-- Transaction A
BEGIN TRANSACTION;
SELECT balance FROM Accounts WHERE account_id = 1; -- Shared lock acquired
-- Transaction B
BEGIN TRANSACTION;
--Try to read the balance (shared lock, should succeed)
SELECT balance FROM Accounts WHERE account_id = 1; -- Shared lock acquired
-- Now, try to update the balance (exclusive lock, should be blocked)
UPDATE Accounts
SET balance = balance + 500
WHERE account_id = 1; -- Exclusive lock request (will be blocked by Transaction A's shared lock)
-- Transaction A
COMMIT; -- Releases the shared lock, unblocks Transaction B