Concurrency control

1

Concurrency control

Concurrency control

2

Introduction

concurrency more than one transaction have access to data

simultaneously part of transaction processing

Concurrency control

3

Outline

motivation three concurrency problems

criterion for correctness of concurrent transactions serialisability

two-phase locking protocol locking

problems deadlocks

Concurrency control

4

Three concurrency problems

the lost update the uncommitted dependency the inconsistent analysis

Concurrency control

5

The lost update problem

Transaction A time Transaction B

RETRIEVE p t1

t2 RETRIEVE p

UPDATE p t3

t4 UPDATE p

Concurrency control

6

The uncommitted dependency problem

Transaction A time Transaction B

t1 UPDATE p

RETRIEVE p t2

t3 ROLLBACK

Concurrency control

7

The uncommitted dependency problem

Transaction A time Transaction B

t1 UPDATE p

UPDATE p t2

t3 ROLLBACK

Concurrency control

8

The inconsistent analysis problem

Transaction A time Transaction B

BEGIN TRANSACTION t0RETRIEVE (SugarA) t1

[sum = 500] t2 BEGIN TRANSACTION t3 RETRIEVE (SugarA)

RETRIEVE (SugarB) t4 UPDATE SugarA TO 0 [sum = 700] t5 COMMIT

RETRIEVE (SugarC) t6[sum = 800]

end result: sum = 800

Concurrency control

9

Issue

all these problems may lead to an inconsistent (incorrect) database

is there a criterion based on which to decide weather a certain set of transaction, if executed concurrently, leads to an incorrect database or not?

Concurrency control

10

Serialisability

criterion for correctness for concurrent execution of transactions: the interleaved execution of a set of transactions is

guaranteed to be correct if it is serialisable correct the DB is not in an inconsistent state serialisability: an interleaved execution has the

same result as some serial execution

Concurrency control

11

Terminology

schedule any execution of a set of transactions

serial / interleaved schedule equivalent schedules

produce the same result independent of the initial state of the DB

Concurrency control

12

Serialisable schedule

Interleaved schedule for transaction 1, 2 and 3

time t1 t2 t3 t4 t5 t6 t7 t8 t9Transaction 1 op11 op12 op13 op14Transaction 2 op21 op22 op23Transaction 3 op31 op32

Equivalent serial schedule (Transaction 1 then Transaction 3 then Transaction 2)

time t1 t2 t3 t4 t5 t6 t7 t8 t9Transaction 1 op11 op12 op13 op14Transaction 2 op21 op22 op23Transaction 3 op31 op32

Concurrency control

13

Notes

the schedules described in the problem examples were not serialisable

neither A-then-B nor B-then-A

two different interleaved transactions might produce different results, yet both can be considered correct

example

Concurrency control

14

Two phase locking theorem

if all transactions obey the two phase locking protocol then all possible interleaved schedules are serialisable

Concurrency control

15

Two phase locking protocol

1.before operating on an object a transaction must acquire a lock on that object

2.after releasing a lock a transaction must not go on to acquire any more locks

phase1 (growing): acquire locks (not simultaneously) phase2 (shrinking): release locks (no further acquisitions allowed) usually locks are released by the COMMIT or ROLLBACK

operation

in practice trade-off between “release lock early and acquire more locks” and

the “two phase locking protocol”

Concurrency control

16

Locking

applicable to tuples types

X, exclusive - write S, shared - read

rules compatibility matrix

Concurrency control

17

Compatibility matrix

existing lock on trequest for lock on t X S none

X refused refused granted

S refused granted granted

no request - - -

Concurrency control

18

Data access protocol

retrieve tuple acquire S lock (on that tuple) update tuple acquire X lock (on that tuple), or

promote the S lock it holds (if it holds one) implicit request

if request for lock is denied transaction goes in wait state until the lock is released

livelock - first come first served

X locks are held until end of transaction (COMMIT or ROLLBACK) (two phase locking protocol)

Concurrency control

19

The uncommitted dependency problem : OK

Transaction A time Transaction B

t1 UPDATE p(X lock on p)

RETRIEVE p t2 (request X lock on p) wait t3 COMMIT / ROLL..wait (release X lock on p)resume RETRIEVE p t4 (acquire S lock on p)

Concurrency control

20

The lost update problem : dead-lock

Transaction A time Transaction B

RETRIEVE p t1 (acquire S lock on p)

t2 RETRIEVE p (acquire S lock on p)

UPDATE p t3 (request X lock on p denied) t4 UPDATE p wait (request X lock on p wait denied) wait wait

Concurrency control

21

Exercises

check what happens in the other uncommitted problem the inconsistent analysis problem the inconsistent analysis problem - example from Date

p. 399 (!there is a little mistake!)

Concurrency control

22

Locking

solves the three basic problems of concurrency

theorem if all the transactions of a set S of transactions comply

with the two phase locking protocol, then all their possible interleaved executions (schedules) are serialisable

however, not all schedules produce the same result• think of examples

introduces another problem: deadlock

Concurrency control

23

Deadlock

Transaction A time Transaction B

acquire LOCK p1 EXCLUSIVE t1

t2 acquire LOCK p2 EXCLUSIVE

request LOCK p2 EXCLUSIVE t3 wait

wait t4 request LOCK p1 EXCLUSIVE

wait wait

Concurrency control

24

Deadlock

two or more transaction are waiting for the other to release a lock

in practice: usually two transactions

detect a deadlock cycle in the wait-for graph, or timing mechanism

break a deadlock rollback a victim transaction what happens to the victim?

Concurrency control

25

Further topics

two phase locking protocol - not feasible in practice (not efficient)

levels of isolation degree of interference

intent locking locking granularity

SQL support no explicit locking facilities it supports different isolation levels (with “locking behind

the scenes”)