Database-concurrency control

When multiple transactions are concurrently executed in the database, data consistency may be damaged. It is necessary for the system to control the interaction between transactions, which is achieved through one of multiple mechanisms of the concurrency control mechanism.

To prevent the transaction from getting starved to death, authorize the lock condition: there is no other transaction holding the lock that conflicts with the m lock on the data item Q; there is no transaction waiting to lock the data item Q and apply to lock the data item before ti.

Common mechanisms are various blocking protocols, timestamp sorting, validity check, and multi-version mechanism.

The blocking protocol is a set of rules that clarify that transactions can lock and unlock data items in the database.Two-phase blocking ProtocolThis transaction is allowed to block new data items only when a transaction has not released any data items. This protocol ensures serializability, but does not avoid deadlocks. In the absence of information on data item access methods, the two-phase blocking protocol is not only necessary but also adequate to ensure serializability.

Tree ProtocolRule: 1. Ti can lock any data item for the first time. 2. After that, Ti locks the data item Q on the premise that Ti holds the lock on the parent item of Q. 3. Unlock data items at any time. 4. After a data item is locked and unlocked by TI, Ti cannot lock the data item.

Timestamp sorting mechanismYou can choose a sequence between each pair of transactions to guarantee serializability. Each transaction in the system corresponds to a unique fixed timestamp. The timestamp of the transaction determines the serializable sequence of the transaction. In this way, if the transaction Ti timestamp is smaller than the transaction TJ timestamp, this mechanism ensures that the generated scheduling is equivalent to a serial scheduling before the transaction Ti appears before the transaction TJ. This mechanism ensures this by rolling back transactions that violate this order.

Thomas write rules:Assume that the transaction Ti sends the write (q) operation:

1. If TS (Ti) <r-timestamp (Q), the Q value produced by TI is the value previously required, but the system has assumed that this value will not be generated. Therefore, the write operation is rejected and Ti rolls back.

2. If TS (Ti) <w-timestamp (Q), the Q value that Ti tries to write is out of date. Therefore, this write operation is sadly ignored.

3. In other cases, perform the write operation and regard w-timestamp (q) As ts (TI ).

In most transactions are read-only transactions. In this way, when a transaction encounters a low frequency of conflict, the validity check mechanism is an appropriate concurrency control mechanism. Each transaction in the system corresponds to a unique fixed timestamp. The serial sequence is determined by the transaction timestamp. In this mechanism, transactions are not delayed. However, to complete a transaction, it must pass the validity check. If the transaction does not pass the validity check, it will roll back to the initial state.

In some cases, multiple data items are grouped into one group, which may be better processed as clustering data items, resulting in multi-level granularity. Small data items are nested in large data items. The hierarchical result can be graphically represented as a tree. Blocking is performed in the order from the root node to the leaf node, and unlocking is performed in the order from the leaf node to the root node.

Multi-version Concurrency ControlThe mechanism creates a new version for this data item when writing data for each transaction. When the read operation is sent, the system selects one of the versions to read. The timestamp and concurrency control mechanism ensure that versions to be read can be selected serially.

Timestamp is the most commonly used technology for multiple versions. For each transaction Ti in the system, we associate a static and unique timestamp with it, that is, TS (TI ). For each data item Q, there is a version sequence <Q1, q2 ,... QM> associated with it.

One way to prevent deadlocks is to use preemption and transaction rollback; the other is the Deadlock Detection and recovery mechanism. The system is in the deadlock status only when the wait graph contains loops.