Acquire all your locks before you release any — grow, then shrink — and serializability follows for free. The rule is a discipline on the timing of locks, not on which locks: one clean condition on a schedule that makes every interleaving it permits conflict-serializable. It is runnable — enumerate the schedules 2PL can produce and each one's conflict graph is provably acyclic. The blue team builds and defends it; the red team breaks the two-phase rule and a cycle appears. The price of the guarantee is the wait-for cycle: 2PL can deadlock.
source K. P. Eswaran, J. N. Gray, R. A. Lorie & I. L. Traiger, The Notions of Consistency and Predicate Locks in a Database System, Comm. ACM 19(11):624–633 (1976) — doi:10.1145/360363.360369 (ACM DL, paywalled — AMBER). Rendered, not quoted.
A transaction locks items to touch them (S to read, X to write). The two-phase rule: split its life into a growing phase (only acquire) and a shrinking phase (only release). The instant it turns — the last acquire before the first release — is the lock point.
Serializability is not asserted; it falls out. Order transactions by lock point and that order is a serial schedule the run is conflict-equivalent to — because the conflict (precedence) graph is then acyclic. The panel's two working transactions, with phase shown live:
Locking alone does nothing; locking with a discipline — grow then shrink — is the protocol that makes the-serializability hold. It converts a runtime property that is expensive to test into a rule you can obey step by step.
But the same rule that forbids the bad interleaving also forces transactions to hold locks they still need while waiting — and two waiters can close a ring. That ring is the-banker-deadlock's wait-for cycle. One sphere buys the next one's problem.
The blue team's live check: enumerate every schedule 2PL can produce for the safe pair and confirm each conflict graph is acyclic. If red breaks the two-phase rule (window 6), a cyclic schedule enters the set and this badge flips.
A schedule interleaves the operations of several transactions, keeping each one's own order. Two operations conflict iff they touch the same item and at least one is a write:
| read | write | |
|---|---|---|
| read | ok | conflict |
| write | conflict | conflict |
Locks enforce this: a shared (S) lock is compatible with other S locks; an exclusive (X) lock is compatible with nothing. Feed a set of transactions into the panel; it schedules them under the two-phase rule and reads out whether the result is serializable.
Every schedule is generated live by a lock manager, and every verdict is computed from the conflict graph on the spot — never looked up.
Three exact results, checked at boot: (1) every schedule 2PL can produce is conflict-serializable — all · produced schedules have acyclic conflict graphs; (2) strict 2PL (hold write locks to commit) admits no dirty read, so no cascading abort; (3) 2PL can deadlock — the deadlock pair reaches a wait-for cycle.
The blue witness (left) re-derives (1) live; the red team (right) breaks the rule and makes it false.
Whole families avoid locking entirely: multi-version (MVCC), optimistic (OCC), timestamp ordering. "Serializable via 2PL" is one engineering choice among several, each with its own failure surface — this instrument shows what 2PL guarantees and what it costs, not that 2PL is the answer.
"Two-phase locking prevents deadlock." Cut. It guarantees serializability, not liveness — it causes deadlocks. Only conservative (static) 2PL, which grabs every lock up front, is deadlock-free.
"2PL prevents cascading aborts." Cut. Basic 2PL does not. You need strict 2PL — hold every write lock until commit — for that. The panel proves the strict version clean and shows a basic order that is dirty.
"Serializable means executed one-at-a-time." Kept, corrected. It means conflict-equivalent to some serial order — the run stays concurrent; only the effect matches a serial one.
The red team's move: let T1 acquire a lock after it has released one — release x early, then reach for y. That breaks the two-phase rule, and a non-serializable interleaving becomes legal. The blue witness (window 7) is watching.
Break the rule and the cyclic schedule r1(x) w2(x) w2(y) r1(y) slips in — its conflict graph gains a cycle, the witness recomputes and turns red. Nothing is faked; the attack is real and it is caught.