Concurrency control 1. 2 Introduction concurrency more than one transaction have access to data...
-
Upload
cole-coleman -
Category
Documents
-
view
236 -
download
0
Transcript of Concurrency control 1. 2 Introduction concurrency more than one transaction have access to data...
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”)