Editing Two-phase locking (section)

== Variants ==
{| class="wikitable"
!
!guarantees conflict-serializability
!guarantees view-serializability
!eliminates deadlocks
!guarantees recoverability
!guarantees strictness
!prevents [[Phantom read|phantom reads]]
!prevents [[Dirty Read|dirty reads]]
|-
|2PL
|Yes
|No
|No
|No
|No
|No
|No
|-
|C2PL
|Yes
|Yes{{Citation needed|reason= |date=January 2024}}
|Yes
|yes?{{Citation needed|reason= |date=January 2024}}
|yes?{{Citation needed|reason= |date=January 2024}}
|No{{Citation needed|reason= |date=January 2024}}
|Yes{{Citation needed|reason= |date=January 2024}}
|-
|S2PL
|Yes
|No
|No
|Yes
|Yes
|Yes
|Yes
|-
|SS2PL
|Yes
|No
|No
|Yes
|Yes
|Yes
|Yes
|}

===Two-phase locking===
According to the '''two-phase locking''' protocol, each transaction handles its locks in two distinct, consecutive phases during the transaction's execution:

# '''Expanding phase''' (aka Growing phase): locks are acquired and no locks are released (the number of locks can only increase).
# '''Shrinking phase''' (aka Contracting phase): locks are released and no locks are acquired.

The two phase locking rules can be summarized as: each transaction must never acquire a lock after it has released a lock. The [[serializability]] property is guaranteed for a schedule with transactions that obey this rule.

Typically, without explicit knowledge in a transaction on end of phase 1, the rule is safely determined only when a transaction has completed processing and requested commit. In this case, all the locks can be released at once (phase 2).

=== Conservative two-phase locking ===
{{Unreferenced section|date=November 2024}}
Conservative two-phase locking (C2PL) differs from 2PL in that transactions obtain all the locks they need before the transactions begin. This is to ensure that a transaction that already holds some locks will not block waiting for other locks. C2PL ''prevents'' [[deadlock (computer science)|deadlock]]s. 

In cases of heavy lock [[Resource contention|contention]], C2PL reduces the time locks are held on average, relative to 2PL and Strict 2PL, because transactions that hold locks are never blocked. In light lock contention, C2PL holds more locks than is necessary, because it is difficult to predict which locks will be needed in the future, thus leading to higher overhead. 

A C2PL transaction will not obtain any locks if it cannot obtain all the locks it needs in its initial request. Furthermore, each transaction needs to declare its read and write set (the data items that will be read/written), which is not always possible. Because of these limitations, C2PL is not used very frequently.

===Strict two-phase locking===
To comply with the strict two-phase locking (S2PL) protocol, a transaction needs to comply with 2PL, and release its ''write (exclusive)'' locks only after the transaction has ended (i.e., either ''committed'' or ''aborted''). On the other hand, ''read (shared)'' locks are released regularly during the shrinking phase. 

Unlike 2PL, S2PL provides [[database transaction schedule#Strict|strictness]] (a special case of cascade-less recoverability). This protocol is not appropriate in [[B-tree|B-trees]] because it causes Bottleneck (while B-trees always starts searching from the parent root). {{Citation needed|reason=This claim that S2PL is not appropriate for B-tree is not supported with citation in the edit. From knowledge, S2PL does not affect how storage / B-tree is being handled. |date=November 2016}}

===Strong strict two-phase locking===
or '''Rigorousness''', or '''Rigorous scheduling''', or '''Rigorous two-phase locking'''

To comply with '''strong strict two-phase locking''' (SS2PL), a transaction's read and write locks are released only after that transaction has ended (i.e., either committed or aborted). A transaction obeying SS2PL has only a phase 1 and lacks a phase 2 until the transaction has completed. Every SS2PL schedule is also an S2PL schedule, but not vice versa.