GATE CS - DATABASES (DBMS):Transactions and Concurrency Control
Mastering transactions and concurrency control concepts and implementation.
Transactions and Concurrency for GATE CS
GATE asks whether a schedule is conflict serializable, what ACID property broke, or how 2PL / locks behave. Draw the precedence graph — do not guess from the English story alone.
ACID (precise)
| Meaning | |
|---|---|
| **Atomicity** | All-or-nothing commit/abort |
| **Consistency** | Integrity constraints hold after commit |
| **Isolation** | Concurrent txs do not see each other’s dirty intermediate states (as required by the isolation level) |
| **Durability** | After commit, changes survive crashes |
Lost update / dirty read / unrepeatable read / phantom are the usual anomaly names.
Schedules and serializability
A schedule is conflict serializable if its precedence (conflict) graph is acyclic. Edge when an operation of conflicts with a later operation of on the same item (RW, WR, WW).
Worked sketch
T1: R(A) W(A) R(B) W(B)
T2: R(A) W(A)
If T2’s W(A) sits between T1’s R(A) and W(A), conflicts create edges — check for a cycle. Cycle ⇒ not conflict serializable.
View serializability is weaker/rarer on the paper; if options say “conflict” vs “view,” use the graph for conflict.
Locks and 2PL
- Shared (S) vs exclusive (X) locks
- Two-phase locking: growing phase (acquire only) then shrinking (release only). Guarantees conflict serializability; can deadlock
- Strict 2PL: hold X locks until commit — avoids cascading aborts
Deadlock
Wait-for graph cycle ⇒ deadlock. Handle by prevention, avoidance (Banker's — more OS), detection + victim abort, or timeout.
Isolation vs the banking story
If two transfers both read the same balance and both write, you typically lose isolation (and may break consistency of the total). Atomicity fails only if a tx partially commits. Durability is about crashes after commit — not the classic double-spend race.