Many students can recite ACID and two-phase locking but get stuck when asked to trace a schedule, draw its precedence graph, or decide whether rollback must cascade. Transaction management connects transaction states with serializability, recoverability, locks, timestamps, and crash recovery. It fits GATE CS preparation and database interviews.
Start with the transaction, not the acronym
A transaction is one logical unit whose operations belong together. Let X = 100 and Y = 40. Transaction T1 transfers 20 using r1(X), X := X - 20, w1(X), r1(Y), Y := Y + 20, w1(Y). Success gives X = 80, Y = 60.
ACID becomes concrete:
Atomicity prevents a half-transfer such as
X = 80, Y = 40.Consistency preserves the declared invariant
X + Y = 140.Isolation makes a concurrent result equivalent to an allowed serial order.
Durability keeps
X = 80, Y = 60after commit and restart.
The DBMS supplies enforcement mechanisms, but application logic must express valid constraints. A transaction moves from active to partially committed to committed. On error, active or partially committed becomes failed, then aborted. The system may restart or terminate it.
Read schedules, conflicts, and anomalies as sequences
In schedule notation, ri(A) reads A, wi(A) writes it, ci commits, and ai aborts. Operations conflict when different transactions touch the same item and at least one writes. Read-read does not conflict; read-write, write-read, and write-write do.
Values reveal anomalies. With A = 500, w1(A = 450), r2(A = 450), a1 is a dirty read because T2 used a value that disappears. In r1(P = 70), w2(P = 75), c2, r1(P = 75), T1 has an unrepeatable read. Interleavings can also lose an update or corrupt a summary.
Conflict-equivalent schedules preserve every conflicting pair's order. A schedule is conflict serializable if it is conflict equivalent to a serial schedule. View serializability is broader because blind writes may allow view equivalence despite a cyclic conflict graph. The earlier DBMS Transactions: ACID, Serializability, 2PL Explained primer concentrates on schedule correctness. Crash recovery remains a separate layer: WAL decides which durable changes must be redone and which incomplete changes must be undone after failure.
Build the precedence graph and prove the schedule unsafe
Start again at X = 100, Y = 40. T1 moves 20 from X to Y; T2 moves 10 from Y to X. Preserve each transaction's internal order and analyse:
S = r1(X), r2(X), w1(X), w2(X), r2(Y), w2(Y), r1(Y), w1(Y)
Step | Operation | Result in the transaction | Database X | Database Y |
|---|---|---|---|---|
1 |
| T1 stores 100 | 100 | 40 |
2 |
| T2 stores 100 | 100 | 40 |
3 |
| T1 writes 100 - 20 | 80 | 40 |
4 |
| T2 writes 100 + 10 | 110 | 40 |
5 |
| T2 stores 40 | 110 | 40 |
6 |
| T2 writes 40 - 10 | 110 | 30 |
7 |
| T1 stores 30 | 110 | 30 |
8 |
| T1 writes 30 + 20 | 110 | 50 |
The final total is 110 + 50 = 160, violating the invariant 140. Serial order T1, T2 gives (100,40) -> (80,60) -> (90,50). Order T2, T1 gives (100,40) -> (110,30) -> (90,50). Both finish at X = 90, Y = 50.
On X, r1(X) before w2(X) gives T1 -> T2; r2(X) before w1(X) gives T2 -> T1. Conflicts on Y also give T2 -> T1. The cycle proves S is not conflict serializable.
Recoverability asks who may commit after reading whose write
Let A = 500, B = 0. In w1(A = 450), r2(A = 450), w2(B = 460), c2, a1, T2 commits after reading T1's uncommitted value. When T1 aborts, A returns to 500, but committed B = 460 came from a value that vanished. This is non-recoverable.
w1(A = 450), r2(A = 450), c1, w2(B = 460), c2 is recoverable because c1 precedes c2, but permits cascading rollback because the read precedes c1. w1(A = 450), c1, r2(A = 450), w2(B = 460), c2 is strict because nobody accesses the written A until T1 finishes. Thus strict => cascadeless => recoverable; reverse implications can fail.
Control concurrency with locks, ordering, and isolation
Shared and exclusive locks follow this table:
Held lock | Request S | Request X |
|---|---|---|
S | Allowed | Blocked |
X | Blocked | Blocked |
Basic 2PL grows by acquiring locks, then shrinks by releasing them. Strict 2PL holds exclusive locks until commit or abort; rigorous 2PL holds all locks that long. Conservative 2PL acquires every required lock before starting, preventing deadlock at the cost of concurrency.
Basic and strict 2PL can deadlock. If T1 holds X(A) and requests X(B), while T2 holds X(B) and requests X(A), the wait-for graph has T1 -> T2 and T2 -> T1. The system must prevent the cycle or abort a victim.
Timestamp ordering rejects obsolete operations instead of waiting. With TS(T1) = 5, RTS(A) = 0, and WTS(A) = 10, T1's write is rejected because 5 is older than the last write timestamp 10. SQL isolation levels move toward serializable behaviour, but implementations vary by DBMS.
Separate crash recovery from schedule recoverability
Write-ahead logging answers a different question. Start with A = 500; T1 changes it to 450. The log has <T1 start>, <T1, A, old=500, new=450>, and <T1 commit>. The update record must reach stable storage before the changed page.
If the update record is durable but commit is not, recovery undoes A to 500. If commit is durable but the page still holds 500, recovery redoes A = 450. A checkpoint bounds recovery work; it does not replace WAL.
Recoverable, cascadeless, and strict schedules govern dependencies among concurrent transactions. Undo, redo, WAL, and checkpoints restore the database after failure.
How GATE and interviews test transaction management
IIT Guwahati's official GATE 2026 CS syllabus lists "Transactions and concurrency control" under Databases. Its official GATE 2026 CS2 paper includes a conflict question. Its lesson is that transactions do not conflict when both only read the same object. This describes 2026, not a future pattern.
Typical tasks ask you to list conflicts, draw a graph, find a serial order from a DAG, classify recoverability, apply lock or timestamp rules, or trace undo and redo. An interview may ask which protocol best balances correctness, deadlock risk, and concurrency.
Five traps deserve a final check:
Read-read is not a conflict.
An acyclic precedence graph proves conflict serializability, not every form of view serializability.
2PL does not mean deadlock-free.
Recoverable does not mean cascadeless.
Isolation cannot repair application logic that violates its own invariant.
The short version and a concrete next step
Use one sequence: define boundaries and invariants, mark conflicts, draw the graph, test read and commit dependencies, identify the control rule, then handle undo or redo separately. The unsafe schedule ends at X = 110, Y = 50; either serial order ends at X = 90, Y = 50. In the strict sequence, c1 precedes r2(A).
Use a balanced drill: five precedence-graph schedules, two recoverability classifications, one deadlock wait-for graph, one timestamp-ordering trace, and one WAL crash trace. That sequence tests each decision without mixing schedule safety with crash recovery.
Use GATE Guidance by Sanchit Sir for structured subject preparation and the GATE Test Series for test-mode practice. Then use DBMS normalisation MCQs to separate schema-design correctness from transaction-time correctness.
