Two Phase Locking ( 2 PL) Protocol

Two phase locking: in basic two phase locking, a transaction must own a read lock on data item x before reading x, and must own a write lock on x before writing x. Read locks conflict with write locks on the same data item, and write locks conflict with other write locks on the same data item. 

Read locks are implicitly requested by the TM by sending reads, and write locks are implicitly requested by the TM by sending writes. Write locks are implicitly released by commits, but in order to release read locks, special lock release operations are required. 

Every transaction obtains locks in a two phase manner. 

During the growing phase, the transaction obtains locks without releasing any locks. During the shrinking phase, the transaction releases locks without obtaining any locks. 

A basic 2PL scheduler follows the following three rules:

1When the 2PL scheduler receives a lock request, it tests whether the requested lock conflicts with another lock that is already set. If so, it queues the lock request. If not, it responds to the lock request by setting the lock.

2Once the 2PL scheduler has a set a lock on a data item, it cannot release the lock until the DM has completed processing of the lock’s corresponding operation.

3Once the 2PL scheduler has released a lock for a transaction, it may not subsequently obtain any locks for the same transaction.

A basic 2PL scheduler requires a strategy to prevent, avoid or detect-and-break deadlocks. 

Various strategies are waits-for-graphs, pre-ordering and pre- declaration of locks, timestamp-priority-based restarts and many others. 

Variations on the basic 2PL method include primary copy 2PL, voting 2PL, multi-version 2PL, centralized 2PL, asymmetric running priority, symmetric running priority, wait-depth limited locking (WDL), dynamic locking with no waiting, asymmetric cautious waiting, wound-wait, wait-die, local wait –depth control (LWDC) and adaptive callback locking. Other variations that make restrictive assumptions about transaction- specification and correctness are weaker consistency semantics, decomposition into subtasks, ordered sharing altruistic locking, proclamations, increment/ decrement locks, sagas and compensations, commutative operations, and other semantic methods.

Dynamic 2PL and static 2PL are two variants of basic 2PL. in dynamic 2PL, a transaction obtains a lock only when it needs to access a corresponding data item. 

In static 2PL, a transaction pre declares and obtains all the locks it may need before it begins any computation. 

Current databases use dynamic 2PL and its variants almost exclusively. Almost all implementations of 2PL enforce strict execution, which requires the scheduler to release all of a transaction’s read locks after the transaction terminates, and all of the transaction’s write locks after the DM has processed the transaction’s commit or abort, 2PL involves the overhead of extra messages needed to acknowledge lock sets and to release locks, and a mechanism to prevent or detect and break deadlocks.