Two-Phase Locking Variants

When you execute a transaction in PostgreSQL, MySQL InnoDB, SQL Server, or Oracle, you're almost certainly using Strict Two-Phase Locking. Not basic 2PL—but its more rigorous cousin that holds exclusive locks until the transaction commits or aborts.

Why does every major database system implement this stricter protocol? The answer lies in a fundamental problem that basic 2PL cannot solve: recoverability. Basic 2PL guarantees serializability—but it can produce schedules where a crash requires cascading rollbacks across transactions that have already committed. This is catastrophic.

Strict 2PL adds a simple but profound constraint: no exclusive lock is released until the transaction ends. This single rule eliminates cascading failures and makes crash recovery predictable and efficient. It's the protocol that makes databases truly reliable.

Before we understand Strict 2PL, we must appreciate the critical flaw in the basic Two-Phase Locking protocol that necessitates this stricter variant.

Basic 2PL Recap:

Basic 2PL divides a transaction's execution into two phases:

1. Growing Phase: Acquire locks; no locks released
2. Shrinking Phase: Release locks; no new locks acquired

Once a transaction releases its first lock, it enters the shrinking phase and cannot acquire new locks. This guarantees conflict serializability—the resulting schedule is equivalent to some serial execution of the transactions.

But there's a devastating catch.

A Concrete Disaster Scenario:

Consider two transactions, T₁ and T₂, operating on account balance A (initially $1000):

The Catastrophe:

T₂ has committed a report showing a balance of $500. But T₁ aborted, so the $500 value never officially existed—A should still be $1000. This creates three critical problems:

1. Data Inconsistency: The committed report contains phantom data
2. Cascading Abort Required: To fix this, T₂ would need to be rolled back—but it already committed
3. Impossible Recovery: We cannot abort a committed transaction; durability guarantees prevent it

This is an unrecoverable schedule. The database has permanently recorded data derived from a transaction that was rolled back. Basic 2PL, despite guaranteeing serializability, allows these disasters.

Strict Two-Phase Locking adds a single, powerful constraint to basic 2PL that eliminates the dirty read vulnerability completely:

A transaction must hold all its exclusive (write) locks until it commits or aborts.

This means exclusive locks are only released as part of the transaction's termination—never before. The lock release and transaction end become a single, atomic event.

Why This Single Rule Fixes Everything:

Holding exclusive locks until transaction end means:

1. No Dirty Reads: Other transactions cannot access written data until the writing transaction commits or aborts
2. No Cascading Aborts: Since uncommitted data is never visible, no transaction can become dependent on uncommitted changes
3. Simple Recovery: After a crash, we can abort incomplete transactions without affecting committed ones
4. Strict Schedules: The resulting schedules are guaranteed to be both serializable AND recoverable

The Subtle Distinction:

In Strict 2PL, the transaction still has two phases (growing and shrinking), but the shrinking phase only applies to shared locks. Exclusive locks have a one-phase behavior: they're acquired during the growing phase and held until the absolute end.

This is why some texts describe Strict 2PL as having a modified shrinking phase—because exclusive locks don't participate in it. They're held until the commit/abort action releases them all at once.

Let's revisit our disaster scenario, but now with Strict 2PL enforced. Observe how the simple rule of holding exclusive locks transforms the outcome:

The Critical Difference:

T₂'s request for a shared lock on A at time t₅ is blocked because T₁ still holds an exclusive lock. T₂ must wait until T₁ either commits or aborts. When T₁ aborts, A is restored to $1000, and only then does T₂ gain access.

T₂ never sees the uncommitted $500 value. Its report correctly shows $1000. The schedule is recoverable because no committed transaction ever read uncommitted data.

Formal Guarantee:

In Strict 2PL, if transaction Tⱼ reads a value written by transaction Tᵢ, then Tᵢ must have already committed or aborted before Tⱼ reads. Since abort restores original values and commit makes changes permanent, Tⱼ always reads a committed, consistent value.

This is precisely the definition of a cascadeless schedule: no transaction reads uncommitted data, so no cascading aborts can ever be necessary.

The relationship between Strict 2PL and schedule recoverability is fundamental to understanding why every production database uses this protocol. Let's establish the formal connection.

Key Insight:

Strict 2PL produces schedules that belong to the intersection of Serializable and Strict schedules. This is not just a theoretical nicety—it's the practical sweet spot:

• Serializable ensures logical correctness (isolation)
• Strict ensures recoverability (durability after failures)

Basic 2PL only guarantees the first. Strict 2PL guarantees both.

Proof that Strict 2PL Produces Strict Schedules:

1. In Strict 2PL, exclusive locks are held until commit or abort
2. Before any transaction Tⱼ can write to a data item X, it must acquire an exclusive lock on X
3. If Tᵢ wrote to X (holding X-lock) and Tⱼ wants to read or write X, Tⱼ must wait for Tᵢ's lock
4. Tᵢ's lock is only released when Tᵢ commits or aborts
5. Therefore, Tⱼ can only access X after Tᵢ terminates
6. This is precisely the definition of a strict schedule ∎

The elegance is in the simplicity: the lock-holding rule mechanically enforces exactly the schedule property we need for safe recovery.

Understanding how databases implement Strict 2PL reveals the engineering behind the theory. The implementation must efficiently manage lock acquisition, blocking, and release while maintaining the strict guarantee.

Critical Implementation Points:

Strict 2PL's safety comes with performance trade-offs that every database administrator must understand. The stricter lock holding increases contention compared to basic 2PL, but this cost is almost always acceptable given the safety guarantees.

Every major relational database implements Strict 2PL, though often combined with other techniques for performance. Understanding these implementations helps when tuning and troubleshooting production systems.

The MVCC Complement:

Modern databases typically combine Strict 2PL for write-write conflicts with MVCC for read-write scenarios:

• Writes still acquire X-locks (Strict 2PL)
• Reads don't acquire locks but see a consistent snapshot (MVCC)
• Result: Readers don't block writers, writers don't block readers

This hybrid approach preserves Strict 2PL's recoverability guarantees while dramatically improving read concurrency. The X-locks still prevent write-write conflicts, and the MVCC layer provides consistent reads without blocking.

Strict 2PL is the cornerstone of transaction processing in production databases. Let's consolidate the key concepts:

What's Next:

Strict 2PL holds exclusive locks until commit. But what about shared locks? The next page explores Rigorous 2PL—an even stricter variant that holds ALL locks (both shared and exclusive) until transaction end. We'll examine when this additional strictness is necessary and what guarantees it provides beyond Strict 2PL.