Compare basic two-phase locking with strict 2PL and with rigorous (strong strict) 2PL: in each variant, which locks are held until the transaction commits, and what does a database engine gain by choosing a stricter variant?

## The one rule they share Every variant here is two-phase: a **growing phase** in which the transaction only acquires locks, then a **shrinking phase** in which it only releases them. The variants differ solely in *when the shrinking phase is allowed to start*, and that single knob controls a large amount of practical database behaviour. ## Basic 2PL A transaction releases each lock as soon as it knows it will acquire nothing more. This yields conflict-serializable schedules (that guarantee comes from the two-phase rule alone) and the most concurrency of the three, because locks are held for the shortest time. But it releases write locks *before commit*. So T2 can acquire a lock on a row T1 has already modified and read T1's uncommitted value. Three bad things follow: 1. **Dirty reads** — T2 sees data that may never exist in a committed state. 2. **Cascading aborts** — if T1 rolls back, T2 must roll back too, and anything that read T2's writes must roll back as well; a single failure can unwind an unbounded fan-out of transactions. 3. **Non-recoverable schedules** — if T2 *commits* before T1 aborts, the system is stuck: it cannot un-commit T2, yet T2's result was derived from work that never happened. Rollback also gets structurally hard, because restoring T1's before-image of the row would silently wipe T2's later write. Because of this, basic 2PL is a teaching device rather than an implementation choice. ## Strict 2PL Strict 2PL adds one requirement: **all exclusive (write) locks are held until the transaction commits or aborts.** Shared locks may still be released earlier. This produces a **strict schedule** — no transaction reads or overwrites an item written by an uncommitted transaction. The payoffs are exactly the three problems above, reversed: - No dirty reads of a write-locked item and therefore **no cascading aborts** ("cascadeless", also called avoiding-cascading-aborts, ACA). - Schedules are **recoverable**: a transaction can only have read committed data, so it never commits on top of work that later disappears. - **Rollback is trivially correct**: since nobody else has touched the item since your write, undo by restoring the before-image cannot destroy another transaction's update. This is why physical/physiological undo logging pairs so naturally with strict 2PL. What strict 2PL does *not* give you is protection on the read side. A shared lock released early means the transaction is no longer two-phase for reads, so repeated reads of the same row can return different values once another transaction's write lock is available. That is precisely how the weaker isolation levels are built. ## Rigorous (strong strict) 2PL Rigorous 2PL holds **every** lock — shared and exclusive — until commit or abort. The shrinking phase collapses into a single instant at commit. The extra property this buys is ordering: because a transaction's lock point now coincides with its commit, and precedence edges always run from an earlier lock point to a later one, **the serialization order equals the commit order**. That is enormously convenient: - The recovery log, ordered by commit, replays to the same state. - Replicas can apply the commit stream serially and stay consistent. - In a distributed setting it composes cleanly with two-phase commit — each participant holds locks until the coordinator's decision, so the global order is the global commit order. (Distributed SS2PL is the standard way to get global serializability without a central scheduler.) Rigorous 2PL is what a lock-based engine's SERIALIZABLE isolation level means in practice. ## The cost curve, and how isolation levels ride it The three variants form a monotonic trade: each step holds locks longer, so lock-wait time, blocking probability, deadlock rate and lock-manager memory all increase, while achievable concurrency falls. Rather than exposing "pick your 2PL variant", engines expose **isolation levels**, which are effectively the same dial: - **READ UNCOMMITTED** — do not take read locks at all. - **READ COMMITTED** — take a shared lock for the instant of the read and drop it immediately (not two-phase for reads); write locks still held to commit, i.e. strict on the write side. Allows non-repeatable reads. - **REPEATABLE READ** — hold shared locks on rows you read until commit, making reads two-phase as well; classically still allows phantoms unless range/predicate locks are added. - **SERIALIZABLE** — rigorous 2PL plus range locking to close phantoms. Notice that even the weakest useful level keeps the *strict* part (write locks to commit). That is not a tuning choice: giving it up would break rollback and recovery, not merely relax isolation. The read side, by contrast, is genuinely negotiable, and that is where the isolation-level dial lives. ## What to say when asked A crisp answer names the three variants by which locks they hold to commit, ties strict to *cascading aborts and safe rollback*, ties rigorous to *serialization order equals commit order*, and closes with the trade: strictness is paid for in lock hold time, which is the dominant driver of contention.