Concurrency Control

Concurrency control in Database management systems ensures that database transactions are performed in-parallel without violating the data integrity of the respective databases. Thus concurrency control is an essential element for correctness in a DBMS where two or more database transactions, executed with time overlap, can access the same data, e.g., virtually in any general-purpose database system.

To ensure correctness, a DBMS usually guarantees that only serialisable transaction schedules are generated, unless serialisability is intentionally relaxed to increase performance, but only in cases where application correctness is not harmed. For maintaining correctness in cases of failed (aborted) transactions (which can always happen for many reasons) schedules also need to have the recoverability (from abort) property.

A DBMS also guarantees that no effect of committed transactions is lost (durability); and no effect of aborted (rolled back) transactions remains in the related database. Overall transaction characterisation is usually summarised by the ACID properties.

ACID Properties

  1. Atomicity – Either the effects of all or none of its operations remain (“all or nothing” semantics) when a transaction is completed (committed or aborted respectively). In other words, to the outside world a committed transaction appears (by its effects on the database) to be indivisible, atomic, and an aborted transaction does not leave effects on the database at all, as if never existed. More details…
  2. Consistency – Every transaction must leave the database in a consistent (correct) state, i.e., maintain the predetermined integrity rules of the database (constraints upon and among the database’s objects). A transaction must transform a database from one consistent state to another consistent state. However, the transaction’s programmer is responsible to make sure that the transaction itself is correct; i.e. it performs correctly what is intended from the application’s point of view. Since a database can be normally changed only by transactions, all the database’s states are consistent. More details…
  3. Isolation – Transactions cannot interfere with each other (as an end result of their executions). Moreover, usually (depending on concurrency control method) the effects of an incomplete transaction are not even visible to another transaction. Providing isolation is the main goal of concurrency control. More details…
  4. Durability – Effects of successful (committed) transactions must persist through crashes. It is typically achieved by recording the transaction’s effects and its commit event in a non-volatile memory. More details…

Why is concurrency control needed?

If transactions are executed sequentially with no overlap in time, no transaction concurrency exists. However, if concurrent transactions with interleaving operations are allowed in an uncontrolled manner, some unexpected, undesirable result may occur.

Here are some typical examples:

  • The lost update problem: A second transaction writes a second value of a data-item (datum) on top of a first value written by a first concurrent transaction, and the first value is lost to other transactions running concurrently which need, by their precedence, to read the first value. The transactions that have read the wrong value end with incorrect results.
  • The dirty read problem: Transactions read a value written by a transaction that has been later aborted. This value disappears from the database upon abort, and should not have been read by any transaction (“dirty read”). The reading transactions end with incorrect results.
  • The incorrect summary problem: While one transaction takes a summary over the values of all the instances of a repeated data-item, a second transaction updates some instances of that data-item. The resulting summary does not reflect a correct result for any (usually needed for correctness) precedence order between the two transactions (if one is executed before the other), but rather some random result, depending on the timing of the updates, and whether certain update results have been included in the summary or not.

Source : Wikipedia

Sub-Pages:

  1. Lock Based Protocol
  2. Graph Based Protocol
  3. Tree Based Protocol
  4. Timestamp Based Protocol
  5. Validation Based Protocol
  6. Wait-die and Wound-wait Schemes
5/5 - (2 votes)

Leave a Reply