In databases and transaction processing, two-phase locking (2PL) is a concurrency control method that ensures serializability [1] [2] . This is also the name of the resulting set of database transaction graphs (history). The protocol uses locks applied by the transaction to data that can block (interpret as signals to stop) other transactions from accessing the same data during the life of the transaction.
Under the 2PL protocol, locks are applied and deleted in two stages:
- Expansion Phase: locks are locked and locks are not blocked.
- Compressing phase: locks are released, and locks are not acquired.
The basic protocol uses two types of locks: Shared and Exclusive locks. Base protocol updates may use more types of locks. Using locks, blocking processes, 2PLs can be deadlocked , which are the result of interlocking two or more transactions.
Content
Data access locks
A lock is a system object associated with a shared resource, such as an element of data of an elementary type, a string in a database, or a memory page. In the database, before accessing an object, it may be necessary to lock the database object (data access lock) through a transaction. Proper use of locks prevents unwanted, incorrect or inconsistent operations with shared resources by other concurrent transactions. When a database object with an existing lock obtained by one transaction needs to be accessed by another transaction, the existing object lock and the type of access expected are checked by the system. If the existing lock type does not allow this particular type of simultaneous access, the transaction attempting to gain access is blocked (according to a predefined agreement / schema). In practice, an object lock does not block a transaction directly above an object, but blocks a transaction from acquiring another lock on the same object, which must be saved / owned by the transaction before performing this operation. Thus, with a locking mechanism, the necessary locking of operations is controlled by a proper locking scheme that indicates which locks are blocking the type of locking.
Two main types of locks are used:
- A write-lock (exclusive lock) is associated with a database object by a transaction (terminology: “a transaction blocks an object” or “acquires a lock for it”) before writing (insert / change / delete) this object.
- A read-lock (shared lock) is associated with a database object by a transaction before reading (extracting the state) of this object.
The general interactions between these types of locks are determined by blocking the behavior as follows:
- An existing write lock on a database object blocks a supposed record on the same object (already requested / released) by another transaction, blocking the write lock from another transaction. The second write lock will be received, and the requested object write will be executed (materialize) after releasing the existing write lock.
- A write lock blocks an intended (already requested / released) read by another transaction, blocking the corresponding read lock.
- A read lock locks the scheduled write with another transaction, locking the corresponding write lock.
- A read lock does not block the intended read by another transaction. The corresponding read lock for the intended read is acquired (in conjunction with the previous reading) immediately after the read request, and then the read destination itself occurs.
There are several options and improvements to these basic types of locks with corresponding variations in the locking behavior. If the first lock blocks another lock, the two locks are called incompatible ; otherwise locks are compatible . Often, blocking interaction locks are presented in the technical literature on the Lock compatibility table. The following is an example of the main types of locks:
Lock type | read lock | write lock |
---|---|---|
read lock | X | |
write lock | X | X |
X indicates incompatibility, that is, a case where a lock of the first type (in the left column) of an object blocks a lock of the second type (in the top row) from being obtained on the same object (another transaction). Typically, an object has a queue of pending transactions (transactions) with corresponding locks. The first locked lock for operation in the queue is acquired as soon as the existing blocking lock is removed from the object, and then the corresponding operation is performed. If a lock for work in the queue is not blocked by any existing lock (simultaneous existence of several compatible locks on the same object is possible), it is acquired immediately.
Comment. In some publications, entries in the table are simply labeled as “compatible” or “incompatible,” or, respectively, “yes” or “no.”
Two-phase locking and its special cases
Two phase lock
According to the two-phase lock protocol , a transaction processes its locks in two different successive phases during the execution of a transaction:
- Expansion phase (or Growing phase): locks are locked and locks are not blocked (the number of locks can only increase).
- Compressing phase : locks are released, and locks are not acquired.
The rule of two phase locks can be summarized as: never get a lock after the lock has been released. The serializability property is guaranteed for a schedule with transactions that obey this rule.
As a rule, with no explicit knowledge of the transaction at the end of phase-1, this is safely determined only when the transaction has completed processing and requested commit. In this case, all locks can be immediately released (phase-2).
Conservative biphasic blocking
The difference between 2PL and C2PL is that C2PL transactions get all the locks necessary to start a transaction. This is done so that a transaction that already contains some locks will not block waiting for other locks. Conservative 2PL prevents deadlocks.
Strict two-phase blocking
In order to comply with the S2PL protocol, a transaction must comply with the requirements of 2PL and release record locks (exclusive) only after its completion, that is, to be either completed or interrupted. On the other hand, reading (sharing) locks are released regularly during phase 2. This protocol is not suitable for B-trees, because it causes a bottleneck (while B-trees always start searching from the parent root).
Strong strict two-phase blocking
or austerity , or a strict planning , or a strict two-phase blocking
In order to comply with strict two-phase blocking (SS2PL), the lock protocol releases the write lock (exception) and read (shared access) used by the transaction only after the transaction is completed, i.e. Only after completion of the execution (readiness) and becoming either perfect or interrupted . This protocol also complies with the S2PL rules. A transaction subject to SS2PL can be considered as having phase-1, which lasts the entire duration of the transaction, rather than phase-2 (or a degenerate phase-2). Thus, only one phase remains, and, apparently, the “two-phase” name is still used because of the historical development of the concept from 2PL, and 2PL - the superclass. The SS2PL schedule feature is also called Rigorousness . This is also the name of the class of schedules that have this property, and the SS2PL schedule is also called “strict schedule”. The term “Stiffness” is free from the unnecessary legacy of the “two-phase” one and also does not depend on any (blocking) mechanism (in principle, other blocking mechanisms can be used). The corresponding property blocking mechanism is sometimes called Rigorous 2PL .
SS2PL is a special case of S2PL, that is, the class of schedules SS2PL is a proper subclass of S2PL (each schedule SS2PL is also a schedule of S2PL, but there are S2PL schedules that are not SS2PL).
SS2PL is a parallel access control protocol for most database systems and has been used since the early days in the 1970s. He proved to be an effective mechanism in many situations and provides, in addition to Serializability, also Strictness (a special case of use without a cascade), which helps to efficiently restore the database, as well as streamline commitments (CO) for participation in distributed environments where CO is based on distributed serializability and global serialization solutions. Being a subset of CO, an efficient implementation of a distributed SS2PL exists without a distributed lock manager (DLM), while distributed interlocks (see below) are resolved automatically. The fact that SS2PL, used in systems with multiple databases, provides global serializability, is known many years before the discovery of CO, but only with CO understood the role of the atomic commitment protocol in maintaining global serializability, as well as automatic monitoring (see distributed SS2PL). In fact, SS2PL, which inherits the Recoverability and CO properties, is more significant than the 2PL subset, which itself in its general form also contains a simple serialization mechanism (however, serializability also implies CO), in an unknown way, to provide SS2PL with any other significant quality. 2PL in its general form, as well as in combination with strict, that is, strict 2PL (S2PL), is not known to be used in practice. The popular SS2PL does not require “End of Phase-1” labeling, like 2PL and S2PL, and therefore easier to implement. In addition, unlike the general 2PL, SS2PL provides, as mentioned above, useful ordering and commitment properties.
There are many variants of SS2PL that use different types of locks with different semantics in different situations, including cases of changing the lock during a transaction. Known options that use blocking multiple grit.
Dead ends in two-phase blocking
Blocks data access lock. Mutual locking between transactions leads to a deadlock situation when the execution of these transactions is stalled and completion cannot be achieved. Thus, it is necessary to eliminate deadlocks in order to execute these transactions and free up the computational resources associated with them. A dead end is a reflection of a potential cycle in a priority column that will occur without blocking. The deadlock is resolved by interrupting the transaction associated with such a potential cycle and interrupting the cycle. It is often detected using a wait schedule (a graph of conflicts blocked by materialization locks, conflicts not materialized in the database due to blocked operations, are not reflected in the priority column and do not affect serializability), which indicates which transaction “waits” for the lock by means of which transaction, and the cycle means deadlock. Interrupting one transaction per cycle is sufficient to break the cycle. If the transaction was interrupted due to a deadlock error, the application can decide what to do next. Typically, an application restarts a transaction from the beginning, but it may delay this action to allow other transactions sufficient time to complete to avoid another deadlock. [6]
In a distributed environment for atomicity, the atomic commitment protocol is used, as a rule, a two-phase fixation protocol (2PC). When recoverable data (data under transaction management) is divided between 2PC participants (i.e. Each data object is controlled by one 2PC participant), then distributed (global) interlocks, deadlocks involving two or more participants in 2PC are automatically solved as follows:
When SS2PL is effectively used in a distributed environment, global interlocks associated with locking generate voting locks in 2PC and are automatically resolved using 2PC (see “Streamlining Commitments” (CO) "in" Exact Characteristics of Locks for Voting on Global Cycles "; except for CO articles, as is well known, this observes.) For the general case of 2PL, global deadlocks are likewise automatically resolved by the synchronization point protocol for step 1 in a distributed transaction ( is achieved by “voting” (notification of the local phase-1) and spreading to participants in a distributed transaction, just like a decision point in the atomic mode, similar to the decision point in CO, a conflict operation in 2PL cannot occur until phase-1 synchronization, with the same resulting deadlock in the case of a global data access deadlock, the deadlock (which is also a global lock-based deadlock) is automatically resolved by the protocol that interrupts some transactions from stvuyuschim ballot, usually using a timeout).
Comment
When data is shared between parties to the atomic commitment protocol (for example, 2PC), an automatic global deadlock error was missed in the literature of the database, although the deadlocks in such systems were a fairly intense area of research:
- For CO and its special case SS2PL, automatic resolution by the atomic commitment protocol was seen only in CO articles. However, in practice it has been observed that in many cases global interlocks are very rarely detected using special resolution mechanisms, less than could be expected (“Why do we see so few global interlocks?”). The reason is that these are probably dead ends, which are automatically resolved and, thus, are not processed and not taken into account by mechanisms;
- For 2PL, in general, the automatic resolution of the (mandatory) protocol synchronization point at the end of phase one (with the same voting mechanism as the protocol of atomic obligations, and the same lack of processing of voting at a deadlock as a result of voting, which leads to a global deadlock resolution) until today (2009). Practically, only the special case of SS2PL is used, where, in addition to the atomic commit protocol, no synchronization is required at the end of the phase of the phase.
In a distributed environment where recoverable data is not shared between the parties to the protocol on the use of atomic obligations, such an automatic resolution does not exist, and distributed interlocks must be solved using special methods.
Notes
- ↑ Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman (1987): Concurrency Control and Recovery in Database Systems , Addison Wesley Publishing Company, ISBN 0-201-10715-5
- ↑ Gerhard Weikum, Gottfried Vossen (2001): Transactional Information Systems , Elsevier, ISBN 1-55860-508-8
Links
- Precedence graph
- Lock (programming)