Concurrency control 1

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 Atime Transaction B RETRIEVE pt1 t2 RETRIEVE p UPDATE pt3 t4 UPDATE p

Concurrency control 6 The uncommitted dependency problem Transaction Atime Transaction B t1 UPDATE p RETRIEVE pt2 t3 ROLLBACK

Concurrency control 7 The uncommitted dependency problem Transaction Atime Transaction B t1 UPDATE p UPDATE pt2 t3 ROLLBACK

Concurrency control 8 The inconsistent analysis problem

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

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

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 AtimeTransaction B t1UPDATE p (X lock on p) RETRIEVE pt2 (request X lock on p) waitt3COMMIT / ROLL.. wait(release X lock on p) resume RETRIEVE pt4 (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 Atime Transaction B acquire LOCK p1 EXCLUSIVE t1 t2 acquire LOCK p2 EXCLUSIVE request LOCK p2 EXCLUSIVE t3 wait wait t4 request LOCK p1 EXCLUSIVEwait

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)