Two-Phase Locking (2PL)

This lesson will elaborate on a specific strategy—two-phase locking (2PL)—databases employ to prevent potential concurrency problems of data transactions.

Concurrency problems

The harsh reality of data systems presents several potential concurrency problems:

• Multiple clients may simultaneously write to the database, overwriting one another’s modifications.

• Data that has only been partially updated may be seen by a client and can be confusing.

• Race conditions among clients can result in unexpected bugs.

Given the case of race conditions and concurrency issues in transactions, the practical approach is achieving isolation using serializability (serializable isolation), and one of the ways to achieve serializability in databases is two-phase locking (2PL).

Two-phase locking (2PL)

Two-phase locking (2PL) makes decisions about a transaction’s ability to access a database item in real time based on a pessimistic concurrency control protocol, i.e., if anything may possibly go wrong (as specified by another transaction already holding a lock), it’s advisable to wait before acting until everything is secure again.

Note: For its implementation, the protocol is not required to be aware, in advance, of every query a transaction will run.

Rules

The following are the three rules that govern the basic functioning of 2PL.

• Rule 1: The lock manager checks for conflicts in locks acquiring, against the incoming operation request and the already set locks by the running operations. It proceeds or waits with the incoming requests based on its conflict findings. The waiting period continues till the conflict resolves. The previous operations release their locks. The lock manager also sends the approved operations to the database manager for its executions and saves the record of the acquired locks for further conflict lookups till the operation completes.
  This rule avoids conflicts between two transactions acquiring locks on the same data. It ensures that the conflicting transactions get scheduled in the same way as their locks-acquiring schedule.

• Rule 2: The lock manager can’t release any lock for any operation until the database manager has marked that operation completed (abort or committed) and notified the lock manager.
  This rule ensures that the database manager performs operations on a data item in the same order specified by the scheduler. Consider the case where $T_1$ acquires a $readlock[a]$ and releases it before the database manager verifies that $read[a]$ has been processed. Then, $T_2$ may acquire a conflicting lock on a, $writelock[a]$, and the lock manager sends $write[a]$ operations to the database manager. Even though the lock manager sends the $read[a]$ before $write[a]$, there is no guarantee that the database manager will receive and process these operations in the same order in the absence of this rule.

• Rule 3: The lock manager will not allow any transaction to acquire any more locks for any data item once it has released even a single lock. This rule is called the two-phase rule, hence the name two-phase locking.
  This refers to the following two phases of its operation.

  • Phase 1: Growing/Expansion: Here, the transaction acquires all the locks and releases no locks.

    • Each transaction asks the DBMS’s lock manager for the locks it requires, and the lock manager either allows or denies requests for locks.

  • Phase 2: Shrinking/Contraction: Here, the transaction releases all the locks and acquires none.

    • This phase is the transaction’s first step after releasing its first lock.

    • Only locks that the transaction previously acquired may be released. During this phase, it cannot acquire new locks.