Database Basics
Transaction T1 took an exclusive lock on row A and then requested a lock on row B, while T2 took an exclusive lock on row B and then requested a lock on row A, so neither can proceed. What does a DBMS typically do when it detects this situation?
- AIt keeps both waiting; one of the locks will eventually be released on its own
- BIt rolls back one transaction to release its locks and lets the other proceed
- CIt commits the updates of both T1 and T2 as they are
Show answer and explanation
Answer: B. It rolls back one transaction to release its locks and lets the other proceed
A state in which two or more transactions wait for each other to release locks, so that none can proceed, is called a deadlock. Waiting alone never resolves it, so many DBMSs detect a deadlock, for example when a cycle appears in the wait-for graph that shows which transaction is waiting for which, and roll back one of them (the victim) to release its locks. The rolled-back transaction is retried later. Another approach is to set an upper limit (timeout) on lock waits and roll back a transaction that exceeds it. As a preventive measure, it is effective to have every transaction acquire locks in a fixed order, such as row A before row B.
- A. Each is waiting for the other, so the locks are never released by waiting alone.
- B. Correct. Rolling back one transaction to release its locks is the usual response.
- C. To commit, a transaction must obtain the locks it needs and finish its work; it cannot commit while stuck waiting.