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 ...