Movatterモバイル変換


[0]ホーム

URL:


Jump to content
WikipediaThe Free Encyclopedia
Search

Two-phase locking

From Wikipedia, the free encyclopedia
Concurrency control method
This article is aboutconcurrency control. For commit consensus within a distributed transaction, seeTwo-phase commit protocol.

Indatabases andtransaction processing,two-phase locking (2PL) is a pessimisticconcurrency control method that guaranteesconflict-serializability.[1][2] It is also the name of the resulting set ofdatabase transactionschedules (histories). The protocol useslocks, applied by a transaction to data, which may block (interpreted as signals to stop) other transactions from accessing the same data during the transaction's life.

By the 2PL protocol, locks are applied and removed in two phases:

  1. Expanding phase: locks are acquired and no locks are released.
  2. Shrinking phase: locks are released and no locks are acquired.

Two types of locks are used by the basic protocol:Shared andExclusive locks. Refinements of the basic protocol may use more lock types. Using locks that block processes, 2PL, S2PL, and SS2PL may be subject todeadlocks that result from the mutual blocking of two or more transactions.

Read and write locks

[edit]

Locks are used to guaranteeserializability. A transaction isholding alock on an object if that transaction has acquired a lock on that object which has not yet been released.

For 2PL, the only used data-access locks areread-locks (shared locks) andwrite-locks (exclusive locks). Below are the rules forread-locks andwrite-locks:

  • A transaction is allowed to read an objectif and only if it is holding aread-lock orwrite-lock on that object.
  • A transaction is allowed to write an object if and only if it is holding awrite-lock on that object.
  • Aschedule (i.e., a set of transactions) is allowed to hold multiple locks on the same object simultaneously if and only if none of those locks are write-locks. If a disallowed lock attempts on being held simultaneously, it will be blocked.
Lock compatibility table
Lock typeread-lockwrite-lock
read-lockX
write-lockXX

Variants

[edit]
guarantees conflict-serializabilityeliminates deadlocksguarantees recoverabilityguarantees strictnesspreventsphantom readspreventsdirty reads
2PLYesNoNoNoNoNo
C2PLYesYesyes?[citation needed]yes?[citation needed]No[citation needed]Yes[citation needed]
S2PLYesNoYesYesYesYes
SS2PLYesNoYesYesYesYes

Note that all conflict serializable schedules are also view serializable (but not vice-versa).

Two-phase locking

[edit]

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

  1. Expanding phase (aka Growing phase): locks are acquired and no locks are released (the number of locks can only increase).
  2. 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. Theserializability 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

[edit]
icon
This sectiondoes notcite anysources. Please helpimprove this section byadding citations to reliable sources. Unsourced material may be challenged andremoved.(November 2024) (Learn how and when to remove this message)

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

In cases of heavy lockcontention, 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

[edit]

To comply with the strict two-phase locking (S2PL) protocol, a transaction needs to comply with 2PL, and release itswrite (exclusive) locks only after the transaction has ended (i.e., eithercommitted oraborted). On the other hand,read (shared) locks are released regularly during the shrinking phase.

Unlike 2PL, S2PL providesstrictness (a special case of cascade-less recoverability). This protocol is not appropriate inB-trees because it causes Bottleneck (while B-trees always starts searching from the parent root).[citation needed]

Strong strict two-phase locking

[edit]

orRigorousness, orRigorous scheduling, orRigorous two-phase locking

To comply withstrong 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.

See also

[edit]

References

[edit]
  1. ^Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman (1987):Concurrency Control and Recovery in Database Systems, Addison Wesley Publishing Company,ISBN 0-201-10715-5
  2. ^Gerhard Weikum, Gottfried Vossen (2001):Transactional Information Systems, Elsevier,ISBN 1-55860-508-8
Retrieved from "https://en.wikipedia.org/w/index.php?title=Two-phase_locking&oldid=1332347564"
Categories:
Hidden categories:

[8]ページ先頭

©2009-2026 Movatter.jp