Transaction T1 holds an exclusive lock on row A and requests a lock on row B. Transaction T2 holds an exclusive lock on row B and requests a lock on row A. Under 2PL, what happens?
A2PL automatically detects the circular wait and aborts the lower-priority transaction
BBoth transactions block indefinitely — a deadlock that 2PL itself does not resolve
C2PL prevents this scenario by requiring transactions to acquire all locks before starting
DT1 is forced to release its lock on A to make progress, then reacquire it later
2PL guarantees serializability, not deadlock-freedom. In this scenario, T1 waits for B while holding A, and T2 waits for A while holding B — a classic circular wait. Neither can proceed without the other releasing, so they block indefinitely. Deadlock resolution (detection via wait-for graphs, or prevention via timestamp ordering) is handled by a separate mechanism, not by the 2PL protocol itself. Option C describes a different protocol (predeclaring all locks) that 2PL does not require.
Question 2 Multiple Choice
A transaction using 2PL acquires a shared lock on row X, reads the data, then releases the shared lock on row X. Later in the same transaction, it needs to acquire a shared lock on row Y. Why does this violate 2PL?
AShared locks cannot be released before exclusive locks in any 2PL implementation
BReleasing the lock on X starts the shrinking phase, so no new lock — including on Y — can be acquired
CRow-level locking in 2PL requires all locks to be acquired before any data is read
DShared locks on different rows are mutually exclusive and cannot both be held
2PL's core rule is: once any lock is released, the transaction enters the shrinking phase and may not acquire any further locks. Releasing the lock on X, even though X is done with, immediately ends the growing phase. Attempting to acquire a new lock on Y afterward violates the protocol and can produce non-serializable schedules. This is also why Strict 2PL holds all locks until commit — not just to avoid cascading aborts, but to prevent transactions from accidentally entering the shrinking phase too early.
Question 3 True / False
Under Strict 2PL, holding all locks until commit or abort prevents cascading aborts.
TTrue
FFalse
Answer: True
True. Basic 2PL allows releasing locks before commit (during the shrinking phase), which creates a risk: if T1 releases a lock and T2 reads the now-unlocked data, then T1 aborts, T2 has read data that was never committed. T2 must also abort — and if T3 read T2's data, T3 must abort too. Strict 2PL prevents this by ensuring that no transaction can read data from T1 until T1 has committed, since T1 holds its locks until then.
Question 4 True / False
Two-Phase Locking guarantees that deadlocks will seldom occur between transactions in a correctly implemented database.
TTrue
FFalse
Answer: False
False. 2PL guarantees serializability — that the concurrent execution is equivalent to some serial ordering — but says nothing about deadlocks. Deadlocks are a separate phenomenon caused by circular lock-wait dependencies, which can happen under any locking protocol. Databases handle deadlocks through separate mechanisms: deadlock detection (checking for cycles in the wait-for graph and aborting a victim) or deadlock prevention (using timestamps to impose a global ordering on lock acquisition).
Question 5 Short Answer
Why does the 2PL rule — never acquire a lock after releasing one — guarantee serializability?
Think about your answer, then reveal below.
Model answer: If a transaction releases a lock and then acquires a new one, another transaction could slip in between: reading the just-released data and producing an interleaving with no equivalent serial ordering. The 2PL rule prevents this by ensuring that each transaction's lock-acquisition window is contiguous and closed. The growing phase establishes a consistent 'claim' on all relevant data; the shrinking phase releases those claims. Because no transaction can acquire a new claim after beginning to release, the partial ordering of transactions induced by their lock conflicts is always acyclic — which is equivalent to the existence of a serializable ordering.
More precisely, 2PL ensures that the lock points (the moment a transaction transitions from growing to shrinking) can be used to construct a serial order that the concurrent schedule is equivalent to. This proof relies on the fact that if T1's lock point precedes T2's, then T1 holds all its locks when T2's shrinking phase begins, preventing any interleaving that would violate the T1-before-T2 order.