CONCURRENCY CONTROL

DATABASEMANAGEMENT

SYSTEM

Mohit Dadu

Concurrency ControlCONCURRENCY: In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other.

• Concurrency control is the process of managing simultaneous operations on the database without having them interfere with one another.

• Concurrent access is relatively easy if all users are only reading data, as there is no way that they can interfere with one another.

Concurrency ControlPurpose 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 rolled-back or waits.

Concurrency Control

Simultaneous execution of transactions over a shared database can create several data integrity and consistency problems:

• Lost Updates.• Uncommitted Data.• Inconsistent retrievals.

Why we need Concurrency Control

Concurrency ControlWhen we need Concurrency Control

1. The amount of data is sufficiently great that at any given time only fraction of the data can be in primary memory & rest should be swapped from secondary memory as needed.

2. Even if the entire database can be present in primary memory, there may be multiple processes.

Concurrency Control Lock-Based Protocols Timestamp-Based Protocols Validation-Based Protocols Multiple Granularity Deadlock Handling Insert and Delete

Operations

Concurrency Control

Lock-Based Protocols Timestamp-Based

ProtocolsValidation-Based

Protocols

Concurrency Control

Timestamp-Based Protocols

This is the most commonly used concurrency protocol. This protocol uses either System Time or Logical Counter as a timestamp.

Lock-based protocols manage the order between the conflicting pairs among transactions at the time of execution, whereas timestamp-based protocols start working as soon as a transaction is created.

Timestamp-Based Protocol

Timestamp-Based ProtocolEvery transaction has a timestamp associated with it, and the ordering is determined by the age of the transaction.Every data item is given the latest read and write-timestamp. This lets the system know when the last ‘read and write’ operation was performed on the data item. Timestamp based algorithm uses timestamp to serialize the execution of concurrent transactions.

This is the responsibility of the protocol system that the conflicting pair of tasks should be executed according to the timestamp values of the transactions.

•The timestamp of transaction Ti is denoted as TS(Ti).•Read time-stamp of data-item X is denoted by R-timestamp(X).•Write time-stamp of data-item X is denoted by W-timestamp(X).

Timestamp-Based Protocol

Timestamp-Based Protocol 1. Transaction Ti issues a write_item(X)

operation:• If TS(Ti) < R-timestamp(X), then the value of

X 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.

• If TS(Ti) < W-timestamp(X), then Ti is attempting to write an obsolete value of X. Hence, this write operation is rejected, and Ti is rolled back.

• Otherwise, the write operation is executed, and W-timestamp(X) is set to TS(Ti).

Timestamp-Based Protocol

• If TS(Ti) W-timestamp(X), then Ti needs to read a value of X that was already overwritten. Hence, the read operation is rejected, and Ti is rolled back.

• If TS(Ti) W-timestamp(X), then the read operation is executed, and R-timestamp(X) is set to the maximum of R-timestamp(X) and TS(Ti).

2. Transaction T issues a read_item(X) operation:

Timestamp-Based Protocol

Advantages:

–Schedules are serializable (like 2PL protocols) –No waiting for transaction, thus, no deadlocks!

•Disadvantages:

-- Starvation is possible (if the same transaction is continually aborted and restarted)

Timestamp-Based ProtocolThomas’s Write Rule:

• If read_TS(X) > TS(Ti) then abort and roll-back Ti and reject the operation.

• If write_TS(X) > TS(Ti), then just ignore the write operation and continue execution. This is because the most recent writes counts in case of two consecutive writes.

• If the conditions given in 1 and 2 above do not occur, then execute write_item(X) of Ti and set write_TS(X) to TS(Ti).

Concurrency Control

Validation-Based Protocols

Validation-Based Protocol Execution of transaction Ti is done in three

phases. 1. Read and execution phase: Transaction Ti

writes only to temporary local variables

2. Validation phase: Transaction Ti performs a ``validation test''

to determine if local variables can be written without violating serializability.

3. Write phase: If Ti is validated, the updates are applied to the database; otherwise, Ti is rolled back.

Also called as optimistic concurrency control since transaction executes fully in the hope that all will go well during validation

Validation-Based Protocol Each transaction Ti has 3 timestamps- Start(Ti) : the time when Ti started its execution- Validation(Ti): the time when Ti entered its

validation phase- Finish(Ti) : the time when Ti finished its write phase Serializability order is determined by timestamp

given at validation time, to increase concurrency. Thus TS(Ti) is given the value of Validation(Ti).

This protocol is useful and gives greater degree of concurrency if probability of conflicts is low. That is because the serializability order is not pre-decided and relatively less transactions will have to be rolled back.

Validation-Based Protocol If for all Ti with TS (Ti) < TS (Tj) either one of

the following condition holds: finish(Ti) < start(Tj) start(Tj) < finish(Ti) < validation(Tj) and

the set of data items written by Ti does not intersect with the set of data items read by Tj.

then validation succeeds and Tj can be committed. Otherwise, validation fails and Tj is aborted.

Validation-Based Protocol Justification: Either first condition is satisfied,

and there is no overlapped execution, or second condition is satisfied and

1. the writes of Tj do not affect reads of Ti since they occur after Ti

has finished its reads. 2. the writes of Ti do not affect reads of Tj

since Tj does not read any item written by Ti.

Validation-Based Protocol Example of schedule produced using validation

T14 T15

read(B)read(B)B:- B-50read(A)A:- A+50

read(A)(validate)display (A+B)

(validate)write (B)write (A)

Thank you