Concurrency

Concurrency is the ability of the database server to process multiple transactions at the same time. Were it not for special mechanisms within the database server, concurrent transactions could interfere with each other to produce inconsistent and incorrect information.

Concurrency control and locking

Concurrency control and locking is the mechanism used by DBMSs for the sharing of data. Atomicity, consistency, and isolation are achieved through concurrency control and locking. When many people may be reading the same data item at the same time, it is usually necessary to ensure that only one application at a time can change a data item. Locking is a way to do this. Because of locking, all changes to a particular data item will be made in the correct order in a transaction.

Need for Concurrency Control

Concurrency is the ability of the DBMS to process more than one transaction at a time. This section overviews briefly several problems that can occur when concurrent transactions execute in an uncontrolled manner. Concrete examples are given to illustrate the problems in details. The related activities and learning tasks that follow give you a chance to evaluate the extent of your understanding of the problems. An important learning objective for this section of the unit is to understand the different types of problems of concurrent executions in OLTP and appreciate the need for concurrency control. We illustrate some of the problems by referring to a simple airline reservation database in which each record is stored for each airline flight. Each record includes the number of reserved seats on that flight as a named data item, among other information. Recal the two transactions T1 and T2 introduced previously.

Transaction T1 cancels N reservations from one flight whose number of reserved seats is stored in the database item named X, and reserves the same number of seats on another flight whose number of reserved seats is stored in the database item named Y. A simpler transaction T2 just reserves M seats on the first flight referenced in transaction T1. To simplify the example, the additional potions of the transactions are not shown, such as checking whether a flight has enough seats available before reserving additional seats. When an airline reservation database program is written, it has the flight numbers, their dates, and the number of seats available for booking as parameters; hence, the same program can be used to execute many transactions, each with different flights and number of seats to be booked. For concurrency control purpose, a transaction is a particular execution of a program on a specific date, flight, and number of seats. The transactions T1 and T2 are specific executions of the programs that refer to the specific flights whose numbers of seats are stored in data item X and Y in the database. Now lets discuss the types of problems we may encounter with these two transactions.

The Three Concurrency Problems

If locking is not available and several users access a database concurrently, problems may occur if their transactions use the same data at the same time. Concurrency problems include:
1. 2. 3.

Lost or buried updates. Uncommitted dependency (dirty read). Inconsistent analysis (nonrepeatable read).

1. Lost Updates
Lost updates occur when two or more transactions select the same row and then update the row based on the value originally selected. Each transaction is unaware of other transactions. The last update overwrites updates made by the other transactions, which results in lost data. For example, two editors make an electronic copy of the same document. Each editor changes the copy independently and then saves the changed copy, thereby overwriting the original document. The editor who saves the changed copy last overwrites changes made by the first editor. This problem could be avoided if the second editor could not make changes until the first editor had finished.

2. Uncommitted Dependency (Dirty Read)

2

Uncommitted dependency occurs when a second transaction selects a row that is being updated by another transaction. The second transaction is reading data that has not been committed yet and may be changed by the transaction updating the row. For example, an editor is making changes to an electronic document. During the changes, a second editor takes a copy of the document that includes all the changes made so far, and distributes the document to the intended audience. The first editor then decides the changes made so far are wrong and removes the edits and saves the document. The distributed document contains edits that no longer exist, and should be treated as if they never existed. This problem could be avoided if no one could read the changed document until the first editor determined that the changes were final.

3. Inconsistent Analysis (Nonrepeatable Read)

Inconsistent analysis occurs when a second transaction accesses the same row several times and reads different data each time. Inconsistent analysis is similar to uncommitted dependency in that another transaction is changing the data that a second transaction is reading. However, in inconsistent analysis, the data read by the second transaction was committed by the transaction that made the change. Also, inconsistent analysis involves multiple reads (two or more) of the same row and each time the information is changed by another transaction; thus, the term nonrepeatable read. For example, an editor reads the same document twice, but between each reading, the writer rewrites the document. When the editor reads the document for the second time, it has changed. The original read was not repeatable. This problem could be avoided if the editor could read the document only after the writer has finished writing it.

THE THREE CONCURRENCY PROBLEMS REVISITED

Now we are in a position to see how the strict two-phase locking protocol solves the three problems described in Section 16.2. Again we consider them one at a time.

The Lost Update Problem The figure is a modified version, showing what would happen to the interleaved execution of that figure under the strict two-phase locking protocol. Transaction A's UPDATE at time 23 is not accepted, because it is an implicit request for an X lock on t, and such a request conflicts with the S lock already 3

held by transaction B; so A goes into a wait state. For analogous reasons, B goes into a wait state at time r4. Now both transactions are unable to proceed, so there is no question of any update being lost. We have thus solved the lost update problem by reducing it to another problem!-but at least we have solved the original problem. The new problem is called deadlock. The Uncommitted Dependency Problem The following figures are modified versions of the previous versions, showing what would happen to the interleaved executions of those figures under the strict two-phase locking protocol. Transaction A's operation at time t2 (RETRIEVE in Fig. 6.7, UPDATE in Fig. 16.8) is not accepted in either case, because it is an implicit request for a lock on t, and such a request conflicts with the X lock already held by B: so A goes into a wait state. It remains in that wait state until B reaches its termination (either COMMIT or ROLLBACK), when B's lock is released and A is able to proceed; committed value and at that point A sees a

(either the pre-B value, if B is rolled back, or the post-B value otherwise). Either and so we have solved the original problem.

way, A is no longer dependent on an uncommitted update,

The Inconsistent Analysis Problem

Fig, 16,9 is a modified version of the previous one, showing what would happen to the inter leaved execution that figure under the strict two-phase locking protocol. Transaction B's UPDATE at time t6 is not accepted, because it is an implicit request for an X lock on ACC1, and such a request conflicts with the S lock already held by A; so B goes into a wait state. Likewise, transaction A's RETRIEVE at time t7 is also not accepted, because it is an implicit request for an S lock on ACC3, and such a request conflicts with the X lock already held by B, so A goes into a wait state also. Again, therefore, we have solved the original problem (the inconsistent analysis problem, in this case) by forcing a deadlock.

The above three problems can be solved by concurrency control technique called locking. There are two types of locks: y y Exclusive locks/write locks (X locks) Shared locks/read locks (S locks)

If transaction A holds an X lock on record p, then transaction B requesting a lock on the same record will be denied. If transaction A holds a S lock on record p, then: y y Transaction B requesting an X lock on the same record will be denied. Transaction C requesting an S lock on p will be granted.

Rules of locking

Locking Techniques for Concurrency Control

One of the main techniques used to control concurrency execution of transactions (that is to provide serializable execution of transactions) is based on the concept of locking data items. A lock is a variable associate with a data item in the database and describes the status of that data item with respect to possible operations that can be applied to the item. Generally speaking, there is one lock for each data item in the database. The overall purpose of locking is to obtain maximum concurrency and minimum delay in processing transactions. In the next a few sections, we will discuss the nature and types of locks, present several 2-phase locking protocols that use locking to guarantee serializability of transaction schedules, and finally, we will discuss two problems associated with the use of locks namely deadlock and livelock and show how these problems are handled.

Types of Locks
The idea of locking is simple: when a transaction needs an assurance that some object, typically a database record that it is accessing in some way, will not change in some unpredictable manner while the transaction is not running on the CPU, it acquires a lock on that object. The lock prevents other transactions from accessing the object. Thus the first transaction can be sure that the object in question will remain in a stable state as long as the transaction desires. There are several types of locks can be used in concurrency control. Binary locks are the simplest but somewhat restrictive in their use. 1. Shared and Exclusive Locks The binary locking scheme described above is too restrictive in general, because at most one transaction can hold on a given item. We should allow several transactions to access the same item X if they all access X for reading purposes only. However, if a transaction is to write an item X, it must have exclusive access to X. For this purpose, we can use a different type of lock called multiple-mode lock. In this scheme, there are three locking operations: read_lock(X), write_lock(X), and unlock(X). That is, a lock associated with an item X, LOCK(X), now has three possible states: read-locked, write-locked, or unlocked. A read-locked item is also called share-locked, because other transactions are allowed to read access that item, whereas a write-locked item is called exclusive-locked, because a single transaction exclusively holds the lock on the item. If a DBMS wishes to read an item, then a shared (S) lock is placed on that item. If a transaction has a shared lock on a database item, it can read the item but not update it. If a DBMS wishes to write (update) an 7

item, then an exclusive (X) lock is placed on that item. If a transaction has an exclusive lock on an item, it can both read and update it. To prevent interference from other transactions, only one transaction can hold an exclusive lock on an item at any given time. If a transaction A holds a shared lock on item X, then a request from another transaction B for an exclusive lock on X will cause B to go into a wait state (and B will wait until As lock is released). A request from transaction B for a shared lock on X will be granted (that is, B will now also hold a shared lock on X). If a transaction A holds an exclusive lock on record X, then a request from transaction B for a lock of either type on X will cause B to go into a wait state (and B will wait until As lock is released). This can be usually summarized by means of a compatibility matrix below that shows which type of lock requests can be granted simultaneously.

For example, when transaction A holds an exclusive (X) lock on data item X, the request from transaction B of an exclusive lock on X will not be granted. If transaction A holds a shared (S) lock on data item X, the request from transaction B of a shared lock will be granted (two transactions can read access the same item simultaneously) but not an exclusive lock. Transaction requests for record locks are normally implicit (at least in most modern systems). In addition, a user can specify explicit locks. When a transaction successfully retrieves a record it automatically acquires an S lock on that record. When a transaction successfully updates a record, it automatically acquires an X lock on that record. If a transaction already holds an S lock on a record then the update operation will promote the S lock to X level as long as T is the only transaction with a S lock on X at the time. Exclusive and shared locks are normally held until the next synchronization point (review the concept of synchronization point). However, a transaction can explicitly release locks that it holds prior to termination using the unlock command.