Transaction T1 holds a lock on row A and is waiting for a lock on row B. Transaction T2 holds a lock on row B and is waiting for a lock on row A. What best describes this situation?
AA race condition — the transaction that commits first wins, and the loser must retry
BA deadlock — a cycle exists in the wait-for graph, and neither transaction can proceed without external intervention
CA livelock — both transactions keep releasing and re-acquiring locks without making progress
DA serialization failure — the transactions have conflicting schedules that cannot be serialized
This is a classic deadlock: T1→T2 (T1 waits for T2) and T2→T1 (T2 waits for T1) form a cycle in the wait-for graph. Neither transaction will ever release its lock voluntarily — each is waiting for the other forever. The database must detect this cycle and abort one transaction (the victim) to break it. A race condition (option A) describes concurrent access where ordering matters but no permanent blocking occurs. Livelock (option C) means transactions keep retrying but fail to progress. Option D describes a serialization anomaly, not a permanent blocking situation.
Question 2 Multiple Choice
A database detects a deadlock and aborts transaction T2, rolling back its changes. What is the correct next step for the application?
AReport a fatal database error — deadlocks indicate data corruption requiring manual recovery
BRetry T2 from scratch — deadlock aborts are normal events that application code should handle with retry logic
CWait for T1 to commit, then re-acquire T2's original locks in reverse order to prevent future deadlocks
DEscalate to table-level locks to prevent the row-level contention that caused the deadlock
Deadlock aborts are not bugs — they are the normal resolution mechanism for lock cycles, and the correct response is to retry the transaction. Application code should always handle deadlock-induced aborts with automatic retry logic. Option A is wrong because no data corruption has occurred; the rollback ensures atomicity. Option C describes lock ordering, which is a prevention strategy, not a recovery response. Option D might reduce future deadlocks but at the cost of concurrency, and it is not the immediate correct response to an abort.
Question 3 True / False
Imposing a global lock-ordering rule (e.g., typically lock rows in ascending primary key order) prevents deadlocks by eliminating the 'hold and wait' Coffman condition.
TTrue
FFalse
Answer: False
Global lock ordering prevents deadlocks by eliminating the *circular wait* condition, not hold-and-wait. Transactions still hold locks while waiting for others — hold-and-wait remains present. What cannot happen is a cycle: if every transaction acquires locks in the same order, no transaction can be waiting for a lock that precedes one it already holds. Mutual exclusion, hold-and-wait, and no-preemption remain; it is circular wait specifically that the global ordering breaks.
Question 4 True / False
A wait-for graph cycle involving three transactions typically requires aborting at least two transactions to resolve the deadlock.
TTrue
FFalse
Answer: False
Any cycle in a wait-for graph can be broken by removing a single edge, which corresponds to aborting one transaction and releasing all its locks. When the victim's locks are released, the transactions that were waiting for them can proceed — the cycle is fully dissolved with one abort. The database typically chooses the victim to minimize rollback cost (fewest rows modified, youngest transaction). Aborting two or more is unnecessary and wasteful.
Question 5 Short Answer
Why is a wait-for graph cycle the right model for detecting database deadlocks, and why can't simple timeouts replace it?
Think about your answer, then reveal below.
Model answer: A wait-for graph cycle directly captures the deadlock condition: a circular dependency that can never self-resolve. If a cycle exists, there is a deadlock; if no cycle exists, there is no deadlock — the detection is exact. Timeouts cannot distinguish a deadlocked transaction from a legitimately slow one (e.g., a complex query). A timeout set too low aborts valid long-running transactions unnecessarily; one set too high leaves deadlocked transactions blocked for too long. Wait-for graph analysis avoids both failure modes by detecting exactly and only real deadlocks.
The practical trade-off is that maintaining the wait-for graph and running periodic cycle detection has overhead, while timeouts are simple to implement. Most production databases accept this overhead because the occasional false abort from timeouts is more disruptive than the graph maintenance cost — especially for applications that depend on long-running transactions.