SERIALIZABLE can be implemented by strict two-phase locking with predicate or next-key locks, or by Serializable Snapshot Isolation (SSI). Contrast how each achieves serial-equivalence, including how each stops a transaction from missing rows another transaction inserts, and what each costs at runtime.

## The two philosophies Serial-equivalence can be achieved by **preventing** bad interleavings before they happen (pessimistic locking) or by **detecting** them and aborting (optimistic validation). Both are correct; they fail differently. ## Strict two-phase locking Two-phase locking means each transaction has a growing phase (acquire locks) and a shrinking phase (release). *Strict* 2PL releases nothing until commit or rollback, which also guarantees recoverability. Shared locks conflict with exclusive locks, so any two transactions whose access sets overlap in a conflicting way are ordered by the lock manager — and the resulting schedule is provably equivalent to a serial one. **The phantom problem.** Row locks are not enough. A transaction that evaluates `WHERE status = 'NEW'` has locked the rows that matched, but a concurrent INSERT of a new matching row conflicts with nothing, and the outcome may match no serial order. Two solutions: - **Predicate locks** — lock the condition itself, so any write whose row satisfies the predicate conflicts. Conceptually clean, expensive to evaluate for arbitrary predicates, so rarely implemented in full. - **Index-range locking (gap / next-key locks)** — the practical approximation. The engine locks index entries *and the gaps between them* along the range your scan traversed, so an insert whose key falls in a locked gap must wait. Precision follows the index: a well-indexed equality predicate locks a narrow range; a predicate with no usable index degenerates into locking everything scanned. **Runtime costs.** Reads block writes and vice versa, so throughput falls as conflicting access grows. Lock-manager memory grows with the number of locks, sometimes triggering escalation to coarser granularity, which collapses concurrency further. Deadlocks are inevitable when transactions acquire locks in different orders; the engine detects them (wait-for graph or timeout) and aborts a victim — so even the pessimistic path needs retry logic. Latency becomes bimodal: fast when uncontended, blocked for the duration of a competing transaction when not. ## Serializable Snapshot Isolation SSI starts from snapshot isolation — every transaction reads a consistent point-in-time view, readers never block writers — and adds *just enough* bookkeeping to catch the schedules snapshot isolation would get wrong. The theory: dependencies between transactions form a graph. Write-write and write-read dependencies are already prevented or ordered by snapshot rules. The dangerous case is the **read-write anti-dependency**: T1 reads something that T2 then writes, so T1 must come before T2 in any equivalent serial order. Non-serializable schedules under snapshot isolation always contain a specific structure: a transaction with an incoming *and* an outgoing anti-dependency (a pivot), with a particular commit ordering. SSI tracks those edges and, when the dangerous structure appears, aborts one of the transactions involved. **How reads are tracked.** Instead of blocking locks, the engine records non-blocking read markers on the tuples, index pages or ranges a transaction examined — these behave like predicate locks for detection purposes only. A later writer touching a marked item creates a tracked edge. Because markers can be escalated to coarser granularity (page, relation) under memory pressure, detection is conservative. **Runtime costs.** No read blocking — the big win, especially for long or read-heavy transactions. But: tracking structures consume memory and must be retained until transactions can no longer participate in a cycle; escalation and the conservative test cause **false-positive aborts**, transactions killed although their schedule was actually fine; abort rates grow with contention, with the size of read sets, and with transaction duration; and even read-only transactions can be aborted as part of a dangerous structure. The guarantee also holds only if *all* participating transactions run at SERIALIZABLE — a concurrent transaction at a weaker level is not tracked and can create anomalies the mechanism cannot see. ## Choosing and tuning - **Read-heavy or long transactions:** SSI is strongly preferable — no read blocking. Under 2PL a long read transaction stalls the write workload. - **Short, hot, highly contended writes:** locking often wins, because a wait costs less than repeatedly redoing work that will lose again. - **Tuning 2PL:** index the predicates so range locks stay narrow, order access consistently, keep transactions short, watch deadlock rate and lock waits. - **Tuning SSI:** index the predicates so read sets and markers stay small, keep transactions short to reduce edge lifetime, size the tracking memory to avoid escalation, watch the abort rate. Note the common thread: **narrow read sets and short transactions help both**, because both mechanisms key off what a transaction read. ## The interview-level summary 2PL buys serial-equivalence with waiting and pays in deadlocks and blocked readers; SSI buys it with dependency tracking and pays in false-positive aborts and memory. Both require retry logic in the application — for a deadlock victim in one case, a serialization failure in the other.