Lock-Based Protocols

 A lock is a mechanism to control concurrent access to a data item

 Data items can be locked in two modes :
1. exclusive (X) mode. Data item can be both read as well as
written. X-lock is requested using lock-X instruction.
2. shared (S) mode. Data item can only be read. S-lock is
requested using lock-S instruction.
 Lock requests are made to concurrency-control manager. Transaction can
proceed only after request is granted.

Database System Concepts - 5th Edition 16.1 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)
 Lock-compatibility matrix

 A transaction may be granted a lock on an item if the requested lock is

compatible with locks already held on the item by other transactions
 Any number of transactions can hold shared locks on an item,
 but if any transaction holds an exclusive on the item no other
transaction may hold any lock on the item.
 If a lock cannot be granted, the requesting transaction is made to wait till
all incompatible locks held by other transactions have been released.
The lock is then granted.

Database System Concepts - 5th Edition 16.2 ©Silberschatz, Korth and Sudarshan
 Lock-Based Protocols (Cont.)
 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 — if A and B
get updated in-between the read of A and B, the displayed sum would be
wrong.
 A locking protocol is a set of rules followed by all transactions while
requesting and releasing locks. Locking protocols restrict the set of
possible schedules.

Database System Concepts - 5th Edition 16.3 ©Silberschatz, Korth and Sudarshan
 Pitfalls of Lock-Based Protocols
 Consider the partial schedule

 Neither T3 nor T4 can make progress — executing lock-S(B) causes T4

to wait for T3 to release its lock on B, while executing lock-X(A) causes
T3 to wait for T4 to release its lock on A.
 Such a situation is called a deadlock.
 To handle a deadlock one of T3 or T4 must be rolled back
and its locks released.

Database System Concepts - 5th Edition 16.4 ©Silberschatz, Korth and Sudarshan
 Pitfalls of Lock-Based Protocols (Cont.)

 The potential for deadlock exists in most locking protocols. Deadlocks

are a necessary evil.
 Starvation is also possible if concurrency control manager is badly
designed. For example:
 A transaction may be waiting for an X-lock on an item, while a
sequence of other transactions request and are granted an S-lock
on the same item.
 The same transaction is repeatedly rolled back due to deadlocks.
 Concurrency control manager can be designed to prevent starvation.

Database System Concepts - 5th Edition 16.5 ©Silberschatz, Korth and Sudarshan
 Binary Lock Protocol

A binary lock is a variable capable of holding only 2 possible

values, i.e., a 1 (depicting a locked state) or a 0 (depicting an
unlocked state). This lock is usually associated with every data
item in the database ( maybe at table level, row level or even the
entire database level).

Database System Concepts - 5th Edition 16.6 ©Silberschatz, Korth and Sudarshan
 Binary Lock Protocols (cont..)

Database System Concepts - 5th Edition 16.7 ©Silberschatz, Korth and Sudarshan
 Binary Lock Protocol (cont..)

Database System Concepts - 5th Edition 16.8 ©Silberschatz, Korth and Sudarshan
 The Two-Phase Locking Protocol
 This is a protocol which ensures conflict-serializable schedules.
 Phase 1: Growing Phase
 transaction may obtain locks
 transaction may not release locks
 Phase 2: Shrinking Phase
 transaction may release locks
 transaction may not obtain locks
 The protocol assures serializability. It can be proved that the
transactions can be serialized in the order of their lock points (i.e.
the point where a transaction acquired its final lock).

Database System Concepts - 5th Edition 16.9 ©Silberschatz, Korth and Sudarshan
 The Two-Phase Locking Protocol (Cont.)

 Two-phase locking does not ensure freedom from deadlocks

 Cascading roll-back is possible under two-phase locking. To avoid
this, follow a modified protocol called strict two-phase locking. Here
a transaction must hold all its exclusive locks till it commits/aborts.
 Rigorous two-phase locking is even stricter: here all locks are held
till commit/abort. In this protocol transactions can be serialized in the
order in which they commit.

Database System Concepts - 5th Edition 16.10 ©Silberschatz, Korth and Sudarshan
 The Two-Phase Locking Protocol (Cont.)

 There can be conflict serializable schedules that cannot be obtained if

two-phase locking is used.
 However, in the absence of extra information (e.g., ordering of access
to data), two-phase locking is needed for conflict serializability in the
following sense:
Given a transaction Ti that does not follow two-phase locking, we can
find a transaction Tj that uses two-phase locking, and a schedule for Ti
and Tj that is not conflict serializable.

Database System Concepts - 5th Edition 16.11 ©Silberschatz, Korth and Sudarshan
 Lock Conversions
 Two-phase locking with lock conversions:
– First Phase:
 can acquire a lock-S on item
 can acquire a lock-X on item
 can convert a lock-S to a lock-X (upgrade)
– Second Phase:
 can release a lock-S
 can release a lock-X
 can convert a lock-X to a lock-S (downgrade)
 This protocol assures serializability. But still relies on the programmer to
insert the various locking instructions.

Database System Concepts - 5th Edition 16.12 ©Silberschatz, Korth and Sudarshan
 Implementation of Locking
 A lock manager can be implemented as a separate process to which
transactions send lock and unlock requests
 The lock manager replies to a lock request by sending a lock grant
messages (or a message asking the transaction to roll back, in case of
a deadlock)
 The requesting transaction waits until its request is answered
 The lock manager maintains a data-structure called a lock table to
record granted locks and pending requests
 The lock table is usually implemented as an in-memory hash table
indexed on the name of the data item being locked

Database System Concepts - 5th Edition 16.13 ©Silberschatz, Korth and Sudarshan
 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 granted requests of the transaction are
deleted
Waiting
 lock manager may keep a list of
locks held by each transaction, to
implement this efficiently

Database System Concepts - 5th Edition 16.14 ©Silberschatz, Korth and Sudarshan
 Deadlock Handling
 Consider the following two transactions:
T1: write (X) T2: write(Y)
write(Y) write(X)
 Schedule with deadlock

T1 T2

lock-X on X
write (X)
lock-X on Y
write (X)
wait for lock-X on X
wait for lock-X on Y

Database System Concepts - 5th Edition 16.15 ©Silberschatz, Korth and Sudarshan
 Deadlock Handling
 System is deadlocked if there is a set of transactions such that every
transaction in the set is waiting for another transaction in the set.
 Deadlock prevention protocols ensure that the system will never
enter into a deadlock state. Some prevention strategies :
 Require that each transaction locks all its data items before it
begins execution (predeclaration).
 Impose partial ordering of all data items and require that a
transaction can lock data items only in the order specified by the
partial order (graph-based protocol).

Database System Concepts - 5th Edition 16.16 ©Silberschatz, Korth and Sudarshan
 More Deadlock Prevention Strategies
 Following schemes use transaction timestamps for the sake of deadlock
prevention alone.
 wait-die scheme — non-preemptive
 older transaction may wait for younger one to release data item.
Younger transactions never wait for older ones; they are rolled back
instead.
 a transaction may die several times before acquiring needed data
item
 wound-wait scheme — preemptive
 older transaction wounds (forces rollback) of younger transaction
instead of waiting for it. Younger transactions may wait for older
ones.
 may be fewer rollbacks than wait-die scheme.

Database System Concepts - 5th Edition 16.17 ©Silberschatz, Korth and Sudarshan