2-Phase Locking (2PL)

To guarantee that concurrent transactions do not corrupt the database, the DBMS must ensure that the schedule of operations is Serializable (meaning the interleaved execution is mathematically equivalent to some sequential execution).

Simply acquiring and releasing locks is not enough. If a transaction acquires a lock, reads data, releases the lock, and then acquires another lock, it can still suffer from inconsistencies. To guarantee serializability, transactions must follow a specific protocol. The most widely used is the Two-Phase Locking Protocol (2PL).

1. The Two Phases

The 2PL protocol dictates that every transaction must issue lock and unlock requests in exactly two distinct phases:

Phase 1: Growing Phase

• A transaction may obtain locks on data items.
• A transaction may upgrade a Shared Lock to an Exclusive Lock.
• Crucial Rule: A transaction cannot release any lock during this phase.

Phase 2: Shrinking Phase

• A transaction may release its locks.
• A transaction may downgrade an Exclusive Lock to a Shared Lock.
• Crucial Rule: Once a transaction releases its very first lock, it enters the shrinking phase. From that exact moment, it cannot acquire any new locks.

2. Variations of 2PL

While basic 2PL guarantees serializability, it has a major flaw: Cascading Rollbacks. If transaction T1 modifies data, releases the lock (entering shrinking phase), and T2 immediately acquires the lock and reads the data. If T1 later fails and aborts, the data T2 read is now invalid. T2 must also be aborted. This creates a chain reaction.

To solve this, modern databases use stricter variations of 2PL:

Strict Two-Phase Locking (Strict 2PL)

• Follows basic 2PL rules.
• Addition: All Exclusive Locks must be held until the transaction fully Commits or Aborts.
• This ensures that no other transaction can read uncommitted data, completely eliminating cascading rollbacks.

Rigorous Two-Phase Locking

• Follows basic 2PL rules.
• Addition: All locks (both Shared and Exclusive) must be held until the transaction fully Commits or Aborts.
• Even easier to implement than Strict 2PL, though it slightly reduces concurrency.

3. 2PL vs Deadlocks

It is extremely important to note that 2PL does not prevent deadlocks. Because transactions are allowed to hold locks while waiting for new ones during the Growing Phase, circular wait conditions can easily occur.

Therefore, any DBMS utilizing 2PL must also implement a deadlock detection subsystem to automatically abort deadlocked transactions.