Concurrency Control

Database Concurrency Control

Purpose of Concurrency Control
To enforce Isolation (through mutual exclusion) among conflicting transactions. To preserve database consistency through consistency preserving execution of transactions. To resolve read-write and write-write conflicts.

Example:
In concurrent execution environment if T1 conflicts with T2 over a data item A, then the existing concurrency control decides if T1 or T2 should get the A and if the other transaction is rolledback or waits.

Slide 18- 2

Concurrency Control Protocols

Lock-Based Protocols - locking data items to prevent multiple transactions from accessing the items concurrently; TimeStamp-based Protocols - A timestamp is a unique identifier for each transaction, generated by the system.

Locking
Locking is a procedure used to control concurrent access to data (to ensure serialisability of concurrent transactions) In order to use a resource (table, row, etc) a transaction must first acquire a lock on that resource This may deny access to other transactions to prevent incorrect results

Two types of locks

Two types of lock
Shared lock (S-lock or read-lock) Exclusive lock (X-lock or write-lock)

Read lock allows several transactions simultaneously to read a resource (but no transactions can change it at the same time) Write lock allows one transaction exclusive access to write to a resource. No other transaction can read this resource at the same time. The lock manager in the DBMS assigns locks and records them in the data dictionary

Locking
Before reading from a resource a transaction must acquire a readlock Before writing to a resource a transaction must acquire a writelock Locks are released on commit/rollback A transaction may not acquire a lock on any resource that is writelocked by another transaction A transaction may not acquire a write-lock on a resource that is locked by another transaction If the requested lock is not available, transaction waits

Database Concurrency Control

The following code performs the lock operation: B: if LOCK (X) = 0 (*item is unlocked*) then LOCK (X) 1 (*lock the item*) else begin wait (until lock (X) = 0) and the lock manager wakes up the transaction); goto B end;

Slide 18- 7

Database Concurrency Control

The following code performs the unlock operation: LOCK (X) 0 (*unlock the item*) if any transactions are waiting then wake up one of the waiting transactions;

Slide 18- 8

 Two-phase locking with lock conversions: First Phase:

can acquire a lock-S on item can acquire a lock-X on item can convert a lock-S to a lock-X (upgrade)

Lock Conversions

Second Phase:
can release a lock-S can release a lock-X can convert a lock-X to a lock-S (downgrade)

This protocol assures serializability.

Automatic Acquisition of Locks

The operation read(D) is processed as: if Ti has a lock on D then read(D) else begin if necessary wait until no other transaction has a lock-X on D grant Ti a lock-S on D; read(D) end

Automatic Acquisition of Locks (Cont.)

write(D) is processed as: if Ti has a lock-X on D then write(D) else begin if necessary wait until no other trans. has any lock on D, if Ti has a lock-S on D then upgrade lock on D to lock-X else grant Ti a lock-X on D write(D) end; All locks are released after commit or abort

 A lock manager can be implemented as a separate process to which transactions send lock and unlock requests The lock manager replies to a lock request by sending a lock grant messages (or a message asking the transaction to roll back, in case of a deadlock) The requesting transaction waits until its request is answered The lock manager maintains a data-structure called a lock table to record granted locks and pending requests
The lock table is usually implemented as an in-memory hash table indexed on the name of the data item being locked
Lock Table

Implementation of Locking

Transaction ID Data item id lock mode Ptr to next data item T1 X1 Read Next

Lock Table

Granted Waiting

Black rectangles indicate granted locks, white ones indicate waiting requests New request is added to the end of the queue of requests for the data item, and granted if it is compatible with all earlier locks Unlock requests result in the request being deleted, and later requests are checked to see if they can now be granted If transaction aborts, all waiting or granted requests of the transaction are deleted lock manager may keep a list of locks held by each transaction, to implement this efficiently

Locks dont guarantee serialisability

X=20, Y=30 T1 read_lock(Y); read_item(Y); unlock(Y); write_lock(X); read_item(X); X:=X+Y; write_item(X); unlock(X);
Y is unlocked too early

T2 read_lock(X); read_item(X); unlock(X); write_lock(Y); read_item(Y); Y:=X+Y; write_item(Y); unlock(Y);

X is unlocked too early

Schedule 1: T1 followed by T2 X=50, Y=80 Schedule 2: T2 followed by T1 X=70, Y=50

The Two-Phase Locking Protocol

This is a protocol which ensures conflict-serializable schedules. Phase 1: Growing Phase
transaction may obtain locks transaction may not release locks

Phase 2: Shrinking Phase

transaction may release locks transaction may not obtain locks

The protocol assures serializability. It can be proved that the transactions can be serialized in the order of their lock points (i.e. the point where a transaction acquired its final lock).

 All locking operations (read_lock, write_lock) precede the first unlock operation in the transactions. Two phases:

Ensuring Serialisability: Two-Phase Locking

expanding phase: new locks on items can be acquired but none can be released shrinking phase: existing locks can be released but no new ones can be acquired
X=20, Y=30 T1 read_lock(Y); read_item(Y); write_lock(X); unlock(Y); read_item(X); X:=X+Y; write_item(X); unlock(X); T2 read_lock(X); read_item(X); write_lock(Y); unlock(X); read_item(Y); Y:=X+Y; write_item(Y); unlock(Y);

 Basic 2PL

Two-Phasing Locking
lock point obtain lock release lock

When a transaction releases a lock, it may not request another lock

number of locks

Phase 1 BEGIN

Phase 2 END

Conservative 2PL or static 2PL

a transaction locks all the items it accesses before the transaction begins execution pre-declaring read and write sets

its locks until after it commits or aborts leads to a strict schedule for recovery
obtain lock
number of locks release lock

Two-Phasing Locking Strict 2PL a transaction does not release any of

BEGIN

period of data END item use

Transaction duration

Consider the following two transactions: T1: write (X) T2: write(Y) write(Y) write(X) Schedule with deadlock

Deadlock Handling

T1 lock-X on X write (X)

T2

lock-X on Y write (Y) wait for lock-X on X

wait for lock-X on Y

Deadlocks
Deadlock: Cycle of transactions waiting for locks to be released by each other. Two ways of dealing with deadlocks:

Deadlock prevention Deadlock detection

Dealing with Deadlock and Starvation

Deadlock prevention A transaction locks all data items it refers to before it begins execution. This way of locking prevents deadlock since a transaction never waits for a data item. The conservative two-phase locking uses this approach.

Deadlock Prevention
Assign priorities based on timestamps. A timsestamp TS(T) which is a unique identifier assigned to transactions based on the order in which they start. If T1 starts before T2, then TS(T1) < TS(T2) (older transaction has the smaller timestamp value) Assume Ti wants a lock that Tj holds. Two policies are possible:

Wait-Die: It Ti has higher priority, Ti waits for Tj; otherwise Ti aborts Wound-wait: If Ti has higher priority, Tj aborts; otherwise Ti waits

If a transaction re-starts, make sure it has its original timestamp

Database Concurrency Control

Dealing with Deadlock and Starvation Deadlock Detection and Resolution

The scheduler maintains a wait-for-graph for detecting cycle. If a cycle exists, then one transaction involved in the cycle is selected (victim) and rolled-back.
Another approach to deal with deadlock is the use of timeouts. In this method, if a transaction waits for a period of time longer than a system-defined timeout period, the system assumes that a transaction may be in a state of deadlock and aborts it regardless of whether a deadlock actually exists or not.

Chapter 18-23

Deadlock Detection
Deadlocks can be described as a wait-for graph, which consists of a pair G = (V,E), If Ti Tj is in E, then there is a directed edge from Ti to Tj, implying that Ti is waiting for Tj to release a data item. When Ti requests a data item currently being held by Tj, then the edge Ti Tj is inserted in the wait-for graph. This edge is removed only when Tj is no longer holding a data item needed by Ti. The system is in a deadlock state if and only if the wait-for graph has a cycle. Must invoke a deadlock-detection algorithm periodically to look for cycles.
V is a set of vertices (all the transactions in the system) E is a set of edges; each element is an ordered pair Ti Tj.

Deadlock Detection (Cont.)

Wait-for graph without a cycle

Wait-for graph with a cycle

Database Concurrency Control

Dealing with Deadlock and Starvation Starvation Starvation occurs when a particular transaction consistently waits or restarted and never gets a chance to proceed further. In a deadlock resolution it is possible that the same transaction may consistently be selected as victim and aborted. This limitation is inherent in all priority based scheduling mechanisms. In Wound-Wait scheme a younger transaction may always be wounded (aborted) by a long running older transaction which may create starvation.
Chapter 18-26

A timsestamp TS(T) which is a unique identifier assigned to transactions based on the order in which they start. If T1 starts before T2, then TS(T1) < TS(T2) (older transaction has the smaller timestamp value) The protocol manages concurrent execution such that the timestamps determine the serializability order.

Timestamp-Based Protocols

In order to assure such behavior, the protocol maintains for each data Q two timestamp values:
W-timestamp(Q) [ WTS (Q) ] is the largest time-stamp of any transaction that executed write(Q) successfully. R-timestamp(Q) [ RTS (Q) ] is the largest time-stamp of any transaction that executed read(Q) successfully.

Timestamp-Based Protocols (Cont.)

Basic Timestamp Ordering utilizes Timestamps to guarantee serializability of concurrent transactions. Timestamp Ordering (TO) Rule if pa(x) and qb(x) are conflicting operations, of Transactions Ta and Tb for item x, then pa(x) is processed before qb(x) iff TS(Ta) < TS(Tb) Suppose a transaction Ti issues a read(Q) 1. If TS(Ti) < WTS(Q), then Ti needs to read a value of Q that was already overwritten. Hence, the read operation is rejected, and Ti is rolled back. 2. If TS(Ti) WTS(Q), then the read operation is executed, and RTS(Q) is set to max(RTS(Q), TS(Ti)).

Timestamp-Based Protocols (Cont.)

Suppose that transaction Ti issues write(Q). 1. If TS(Ti) < RTS(Q), then the value of Q that Ti is producing was needed previously, and the system assumed that that value would never be produced. Hence, the write operation is rejected, and Ti is rolled back. 2. If TS(Ti) < WTS(Q), then Ti is attempting to write an obsolete value of Q. Hence, this write operation is rejected, and Ti is rolled back. 3. Otherwise, the write operation is executed, and WTS(Q) is set to TS(Ti).

Example Use of the Protocol

A partial schedule for several data items for transactions withtimestamps 1, 2, 3, 4, 5
T1

T2

T3

T4

read(Y)

read(Y) write(Y) write(Z) read(X) abort write(Z) abort

T5 read(X)

read(Z)

read(X)

write(Y) write(Z)

Correctness of Timestamp-Ordering Protocol

The timestamp-ordering protocol guarantees serializability since all the arcs in the precedence graph are of the form:
transaction with smaller timestamp transaction with larger timestamp

Thus, there will be no cycles in the precedence graph Timestamp protocol ensures freedom from deadlock as no transaction ever waits.