concurrency control - doc.ic.ac.ukpjm/db/lectures/concurrency-lecture.pdf · concurrency control...
TRANSCRIPT
Concurrency Control
Peter Mc.Brien
Dept. of Computing, Imperial College London
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 1 / 53
Transactions ACID properties
Transactions: ACID properties
ACID properties
database management systems (DBMS) implements indivisible tasks calledtransactions
Atomicity all or nothingConsistency consistent before → consistent afterIsolation independent of any other transactionDurability completed transaction are durable
BEGIN TRANSACTIONUPDATE branchSET cash=cash −10000.00WHERE so r t code =56
UPDATE branchSET cash=cash +10000.00WHERE so r t code =34
COMMIT TRANSACTION
Note that if total cash is £137,246.12before the transaction, then it will bethe same after the transaction.
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 2 / 53
Transactions ACID properties
Example Data
branchsortcode bname cash
56 ’Wimbledon’ 94340.4534 ’Goodge St’ 8900.6767 ’Strand’ 34005.00
movementmid no amount tdate1000 100 2300.00 5/1/19991001 101 4000.00 5/1/19991002 100 -223.45 8/1/19991004 107 -100.00 11/1/19991005 103 145.50 12/1/19991006 100 10.23 15/1/19991007 107 345.56 15/1/19991008 101 1230.00 15/1/19991009 119 5600.00 18/1/1999
accountno type cname rate? sortcode
100 ’current’ ’McBrien, P.’ NULL 67101 ’deposit’ ’McBrien, P.’ 5.25 67103 ’current’ ’Boyd, M.’ NULL 34107 ’current’ ’Poulovassilis, A.’ NULL 56119 ’deposit’ ’Poulovassilis, A.’ 5.50 56125 ’current’ ’Bailey, J.’ NULL 56
key branch(sortcode)key branch(bname)key movement(mid)key account(no)
movement(no)fk⇒ account(no)
account(sortcode)fk⇒ branch(sortcode)
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 3 / 53
Transactions ACID properties
Transaction Properties: Atomicity
BEGIN TRANSACTIONUPDATE branchSET cash=cash −10000.00WHERE so r t c od e=56
CRASH
Suppose that the system crashes half way through processing a cash transfer, and thefirst part of the transfer has been written to disc
The database on disc is left in an inconsistent state, with £10,000 ‘missing’
A DBMS implementing Atomicity of transactions would on restart UNDO thechange to branch 56
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 4 / 53
Transactions ACID properties
Transaction Properties: Consistency
BEGIN TRANSACTIONDELETE FROM branchWHERE so r t c od e=56
INSERT INTO accountVALUES (100 , ’ Smith , J ’ , ’ d e p o s i t ’ , 5 . 0 0 , 34 )
END TRANSACTION
Suppose that a user deletes branch with sortcode 56, and inserts a deposit accountnumber 100 for John Smith at branch sortcode 34
The database is left in an inconsistent state for two reasons
it has three accounts recorded for a branch that appears not to exist, andit has two records for account number 100, with different details for the account
A DBMS implementing Consistency of transactions would forbid both of thesechanges to the database
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 5 / 53
Transactions ACID properties
Transaction Properties: Isolation
BEGIN TRANSACTIONUPDATE branchSET cash=cash −10000.00WHERE so r t c od e=56
UPDATE branchSET cash=cash +10000.00WHERE so r t c od e=34
END TRANSACTION
BEGIN TRANSACTION
SELECT SUM( cash ) AS n e t c a shFROM branch
END TRANSACTION
Suppose that the system sums the cash in the bank in one transaction, half waythrough processing a cash transfer in another transaction
The result of the summation of cash in the bank erroneously reports that£10,000 is missing
A DBMS implementing Isolation of transactions ensures that transactionsalways report results based on the values of committed transactions
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 6 / 53
Transactions ACID properties
Transaction Properties: Durability
BEGIN TRANSACTIONUPDATE branchSET cash=cash −10000.00WHERE so r t c od e=56
UPDATE branchSET cash=cash+10000.00WHERE so r t c od e=34
END TRANSACTION
CRASH
Suppose that the system crashes after informing the user that it has committed thetransfer of cash, but has not yet written to disc the update to branch 34
The database on disc is left in an inconsistent state, with £10,000 ‘missing’
A DBMS implementing Durability of transactions would on restart completethe change to branch 34 (or alternatively never inform a user of commitmentwith writing the results to disc).
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 7 / 53
Transactions ACID properties
SQL Conversion to Histories
branchsortcode bname cash
56 ’Wimbledon’ 94340.4534 ’Goodge St’ 8900.6767 ’Strand’ 34005.00
BEGIN TRANSACTION T1UPDATE branchSET cash=cash-10000.00WHERE sortcode=56
UPDATE branchSET cash=cash+10000.00WHERE sortcode=34
COMMIT TRANSACTION T1
H1 = r1[b56] , cash=94340.45,
w1[b56] , cash=84340.45,
r1[b34] , cash=8900.67,
w1[b34] , cash=18900.67, c1
history of transaction Tn
1 Begin transaction bn (only given if necessary for discussion)
2 Various read operations on objects rn[oj ] and write operations wn[oj ]
3 Either cn for the commitment of the transaction, or an for the abort of thetransaction
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 8 / 53
Transactions ACID properties
SQL Conversion to Histories
branchsortcode bname cash
56 ’Wimbledon’ 84340.4534 ’Goodge St’ 18900.6767 ’Strand’ 34005.00
BEGIN TRANSACTION T2UPDATE branchSET cash=cash-2000.00WHERE sortcode=34
UPDATE branchSET cash=cash+2000.00WHERE sortcode=67
COMMIT TRANSACTION T2
H2 = r2[b34] , cash=18900.67,
w2[b34] , cash=16900.67,
r2[b67] , cash=34005.00,
w2[b67] , cash=36005.00, c2
history of transaction Tn
1 Begin transaction bn (only given if necessary for discussion)
2 Various read operations on objects rn[oj ] and write operations wn[oj ]
3 Either cn for the commitment of the transaction, or an for the abort of thetransaction
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 9 / 53
Concurrency Definition
Concurrent Execution
Concurrent Execution of Transactions
Interleaving of several transaction histories
Order of operations within each history preserved
H1 = r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1
H2 = r2[b34] , w2[b34] , r2[b67] , w2[b67] , c2
Some possible concurrent executions are
Hx = r2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , w2[b34] , r2[b67] , w2[b67] , c2
Hy = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , r2[b67] , w2[b67] , c2 , c1
Hz = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , r2[b67] , w2[b67] , c2
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 10 / 53
Concurrency Definition
Which concurrent executions should be allowed?
Concurrency control → controlling interaction
serialisability
A concurrent execution of transactions should always has the same end result assome serial execution of those same transactions
recoverability
No transaction commits depending on data that has been produced by anothertransaction that has yet to commit
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 11 / 53
Concurrency Definition
Quiz 1: Serialisability and Recoverability (1)
Hx = r2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , w2[b34] , r2[b67] , w2[b67] , c2
Is Hx
A
Not Serialisable, Not Recoverable
B
Not Serialisable, Recoverable
C
Serialisable, Not Recoverable
D
Serialisable, Recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 12 / 53
Concurrency Definition
Quiz 2: Serialisability and Recoverability (2)
Hy = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , r2[b67] , w2[b67] , c2 , c1
Is Hy
A
Not Serialisable, Not Recoverable
B
Not Serialisable, Recoverable
C
Serialisable, Not Recoverable
D
Serialisable, Recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 13 / 53
Concurrency Definition
Quiz 3: Serialisability and Recoverability (3)
Hz = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , r2[b67] , w2[b67] , c2
Is Hz
A
Not Serialisable, Not Recoverable
B
Not Serialisable, Recoverable
C
Serialisable, Not Recoverable
D
Serialisable, Recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 14 / 53
Concurrency Anomalies
Anomaly 1: Lost Update
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1
BEGIN TRANSACTION T2EXEC move cash(34,67,2000.00)
COMMIT TRANSACTION T2
r2[b34] , w2[b34] , r2[b67] , w2[b67] , c2
r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r1[b34] , cash=8900.67,
r2[b34] , cash=8900.67, w1[b34] , cash=18900.67, c1 , w2[b34] , cash=6900.42,
r2[b67] , cash=34005.00, w2[b67] , cash=36005.25, c2
− serialisable + recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 15 / 53
Concurrency Anomalies
Anomaly 1: Lost Update
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1
BEGIN TRANSACTION T2EXEC move cash(34,67,2000.00)
COMMIT TRANSACTION T2
r2[b34] , w2[b34] , r2[b67] , w2[b67] , c2
r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r1[b34] , cash=8900.67,
r2[b34] , cash=8900.67, lostupdate, c1 , w2[b34] , cash=6900.42,
r2[b67] , cash=34005.00, w2[b67] , cash=36005.25, c2
− serialisable + recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 15 / 53
Concurrency Anomalies
Anomaly 2: Inconsistent analysis
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1
BEGIN TRANSACTION T4SELECT SUM(cash) FROM branch
COMMIT TRANSACTION T4
H4 = r4[b56] , r4[b34] , r4[b67] , c4
r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r4[b56] , cash=84340.45,
r4[b34] , cash=8900.67, r4[b67] , cash=34005.00, r1[b34] , cash=8900.67,
w1[b34] , cash=18900.67, c1 , c4
− serialisable + recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 16 / 53
Concurrency Anomalies
Anomaly 3: Dirty Reads
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1
BEGIN TRANSACTION T2EXEC move cash(34,67,2000.00)
COMMIT TRANSACTION T2
r2[b34] , w2[b34] , r2[b67] , w2[b67] , c2
r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r2[b34] , cash=8900.67,
w2[b34] , cash=6900.42, r1[b34] , cash=6900.67, w1[b34] , cash=16900.67, c1 ,
r2[b67] , cash=34005.00, w2[b67] , cash=36005.25, a2
+ serialisable − recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 17 / 53
Concurrency Anomalies
Quiz 4: Anomalies (1)
Hx = r2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , w2[b34] , r2[b67] , w2[b67] , c2
Which anomaly does Hx suffer?
A
None
B
Lost Update
C
Inconsistent Analysis
D
Dirty Read
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 18 / 53
Concurrency Anomalies
Quiz 5: Anomalies (2)
Hy = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , r2[b67] , w2[b67] , c2 , c1
Which anomaly does Hy suffer?
A
None
B
Lost Update
C
Inconsistent Analysis
D
Dirty Read
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 19 / 53
Concurrency Anomalies
Quiz 6: Anomalies (3)
Hz = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , r2[b67] , w2[b67] , c2
Which anomaly does Hz suffer?
A
None
B
Lost Update
C
Inconsistent Analysis
D
Dirty Read
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 20 / 53
Concurrency Anomalies
Patterns of operations associated with Anomalies
Anomaly PatternDirty Write w1[o] ≺ w2[o] ≺ e1Dirty Read w1[o] ≺ r2[o] ≺ e1Inconsistent Analysis r1[oa] ≺ w2[oa], w2[ob] ≺ r1[ob]Lost Update r1[o] ≺ w2[o] ≺ w1[o]
Notation
ei means either ci or ai occurring
opa ≺ opb mean opa occurs before opb in a history
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 21 / 53
Concurrency Anomalies
Worksheet: Anomalies
rental charge
H1 = r1[d1000] , w1[d1000] , r1[d1001] , w1[d1001] , r1[d1002] , w1[d1002]
transfer charge
H2 = r2[d1000] , w2[d1000] , r2[d1002] , w2[d1002]
total charge
H3 = r3[d1000] , r3[d1001] , r3[d1002]
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 22 / 53
Concurrency Anomalies
Account Table
accountno type cname rate? sortcode100 ’current’ ’McBrien, P.’ NULL 67101 ’deposit’ ’McBrien, P.’ 5.25 67103 ’current’ ’Boyd, M.’ NULL 34107 ’current’ ’Poulovassilis, A.’ NULL 56119 ’deposit’ ’Poulovassilis, A.’ 5.50 56125 ’current’ ’Bailey, J.’ NULL 56
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 23 / 53
Concurrency Anomalies
Anomaly 4: Dirty Writes
BEGIN TRANSACTION T5UPDATE accountSET rate=5.5WHERE type=’deposit’
COMMIT TRANSACTION T5
H5 = w5[a101] , rate=5.5,
w5[a119] , rate=5.5, c5
BEGIN TRANSACTION T6UPDATE accountSET rate=6.0WHERE type=’deposit’
COMMIT TRANSACTION T6
H6 = w6[a101] , rate=6.0,
w6[a119] , rate=6.0, c6
w6[a101] , rate=6.0, w5[a101] , rate=5.5, w5[a119] , rate=5.5,
w6[a119] , rate=6.0, c5 , c6
− serialisable + recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 24 / 53
Serialisability
Serialisable Transaction Execution
Solve anomalies → H ≡ serial execution
Only interested in the committed projection
Hc =
r1[b56] , r2[b34] , w2[b34] ,
r3[m1000] , r3[m1001] , r3[m1002] ,
w1[b56] , r4[b56] ,
r3[m1003] , r3[m1004] , r3[m1005] ,
r1[b34] , a3 , w1[b34] , c1 , r4[b34] ,
r2[b67] , w2[b67] , c2 , r4[b67] , c4
C(Hc) =
r1[b56] , r2[b34] , w2[b34] ,
w1[b56] , r4[b56] ,
r1[b34] , w1[b34] , c1 , r4[b34] ,
r2[b67] , w2[b67] , c2 , r4[b67] , c4
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 25 / 53
Serialisability
Possible Serial Equivalents
Hcp = r1[b56] , r2[b34] , w2[b34] , w1[b56] , r4[b56] , r1[b34] , w1[b34] , c1 , r4[b34] , r2[b67] ,
w2[b67] , c2 , r4[b67] , c4
H1 , H2 , H4 H1 , H4 , H2 H2 , H1 , H4 H2 , H4 , H1 H4 , H1 , H2 H4 , H2 , H1
how to determine that histories are equivalent?
how to check this during execution?
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 26 / 53
Serialisability
Conflicts: Potential For Problems
conflict
A conflict occurs when there is an interaction between two transactions
rx[o] and wy[o] are in H where x 6= y
or
wx[o] and wy [o] are in H where x 6= y
Only consider pairs where there is
no third operation rwz[o] between
the pair of operations that conflicts
with both
conflicts
Hx = r2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , w2[b34] , r2[b67] , w2[b67] , c2
Hy = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , r2[b67] , w2[b67] , c2 , c1
Hz = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , r2[b67] , w2[b67] , c2
Conflicts
w2[b34] → r1[b34] T1 reads from T2 in Hy,Hz
w1[b34] → w2[b34] T2 writes over T1 in Hx
r2[b34] → w1[b34] T1 writes after T2 reads in Hx
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 27 / 53
Serialisability
Quiz 7: Conflicts
Hw =
r2[a100] , w2[a100] , r2[a107] , r1[a119] , w1[a119] , r1[a107] , w1[a107] , c1 , w2[a107] , c2
Which of the following is not a conflict in Hw?
A
r2[a107] → r1[a107]
B
r2[a107] → w1[a107]
C
r1[a107] → w2[a107]
D
w1[a107] → w2[a107]
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 28 / 53
Serialisability
Conflict Equivalence and Conflict Serialisable
Conflict Equivalence
Two histories Hi and Hj are conflict equivalent if:
1 Contain the same set of operations
2 Order conflicts (of non-aborted transactions) in the same way.
Conflict Serialisable
a history H is conflict serialisable (CSR) if C(H) ≡CE a serial history
Failure to be conflict serialisable
Hx = r2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , w2[b34] , r2[b67] , w2[b67] , c2
Contains conflicts r2[b34] → w1[b34] and w1[b34] → w2[b34] and so is not conflict
equivalence to H1,H2 nor H2,H1, and hence is not conflict serialisable.
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 29 / 53
Serialisability
Serialisation Graph
Serialisation Graph
A serialisation graph SG(H) contains a node for each transaction in H , and anedge Ti → Tj if there is some object o for which a conflict rwi[o] → rwj [o] exists in H .If SG(H) is acyclic, then H is conflict serialisable.
Demonstrating that a History is CSR
Given Hcp= r1[b56] , r2[b34] , w2[b34] , w1[b56] , r4[b56] , r1[b34] , w1[b34] ,
c1 , r4[b34] , r2[b67] , w2[b67] , c2 , r4[b67] , c4
Conflicts are w2[b34] → r1[b34] , w1[b56] → r4[b56] , w1[b34] → r4[b34] ,
w2[b67] → r4[b67]
SG(Hc)
T2 T1 T4
SG(Hcp) is acyclic, therefore Hcp is CSR. Serialisation order T2, T1, T4P.J. Mc.Brien (Computing, Imperial) Concurrency Control 30 / 53
Serialisability
Worksheet: Serialisability
H1 = r1[o1] , w1[o1] , w1[o2] , w1[o3] , c1
H2 = r2[o2] , w2[o2] , w2[o1] , c2
H3 = r3[o1] , w3[o1] , w3[o2] , c3
H= r1[o1] , w1[o1] , r2[o2] , w2[o2] , w2[o1] , c2 , w1[o2] , r3[o1] , w3[o1] ,
w3[o2] , c3 , w1[o3] , c1
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 31 / 53
Recoverability Definition
Recoverability
Serialisability necessary for isolation and consistency of committed transactions
Recoverability necessary for isolation and consistency when there are alsoaborted transactions
Recoverable execution
A recoverable (RC) history H has no transaction committing before anothertransaction from which it read
Execution avoiding cascading aborts
A history which avoids cascading aborts (ACA) does not read from anon-committed transaction
Strict execution
A strict (ST) history does not read from a non-committed transaction nor writeover a non-committed transaction
ST ⊂ ACA ⊂ RC
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 32 / 53
Recoverability Types of Recoverability
Non-recoverable executions
BEGIN TRANSACTION T1UPDATE branchSET cash=cash-10000.00WHERE sortcode=56UPDATE branchSET cash=cash+10000.00WHERE sortcode=34
COMMIT TRANSACTION T1
H1 = r1[b56] , w1[b56] , a1
BEGIN TRANSACTION T4SELECT SUM(cash) FROM branch
COMMIT TRANSACTION T4
H4 = r4[b56] , r4[b34] , r4[b67] , c4
Hc = r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r4[b56] , cash=84340.45,
r4[b34] , cash=8900.67, r4[b67] , cash=34005.00, c4 , a1Hc 6∈ RC
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 33 / 53
Recoverability Types of Recoverability
Cascading Aborts
BEGIN TRANSACTION T1UPDATE branchSET cash=cash-10000.00WHERE sortcode=56UPDATE branchSET cash=cash+10000.00WHERE sortcode=34
COMMIT TRANSACTION T1
H1 = r1[b56] , w1[b56] , a1
BEGIN TRANSACTION T4SELECT SUM(cash) FROM branch
COMMIT TRANSACTION T4
H4 = r4[b56] , r4[b34] , r4[b67] , c4
Hc = r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r4[b56] , cash=84340.45,
r4[b34] , cash=8900.67, r4[b67] , cash=34005.00, a1 , a4
Hc ∈ RC
Hc 6∈ ACA
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 34 / 53
Recoverability Types of Recoverability
Strict Execution
BEGIN TRANSACTION T5UPDATE accountSET rate=5.5WHERE type=’deposit’
COMMIT TRANSACTION T5
H5 = w5[a101] , rate=5.5,
w5[a119] , rate=5.5, a5
BEGIN TRANSACTION T6UPDATE accountSET rate=6.0WHERE type=’deposit’
COMMIT TRANSACTION T6
H6 = w6[a101] , rate=6.0,
w6[a119] , rate=6.0, c6
Hc = w6[a101] , rate=6.0, w5[a101] , rate=5.5,
w5[a119] , rate=5.5, w6[a119] , rate=6.0, a5 , c6
Hc ∈ ACAHc 6∈ ST
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 35 / 53
Recoverability Types of Recoverability
Quiz 8: Recoverability
Hz = r2[b34] , w2[b34] , r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1 , r2[b67] , w2[b67] , c2
Which describes the recoverability of Hz?
A
Non-recoverable
B
Recoverable
C
Avoids Cascading Aborts
D
Strict
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 36 / 53
Recoverability Types of Recoverability
Worksheet: Recoverability
Hw = r2[o1] , r2[o2] , w2[o2] , r1[o2] , w2[o1] , r2[o3] , c2 , c1
Hx = r2[o1] , r2[o2] , w2[o1] , w2[o2] , w1[o1] , w1[o2] , c1 , r2[o3] , c2
Hy = r2[o1] , r2[o2] , w2[o2] , r1[o2] , w2[o1] , c1 , r2[o3] , c2
Hz = r2[o1] , w1[o1] , r2[o2] , w2[o2] , r2[o3] , c2 , r1[o2] , w1[o2] , w1[o3] , c1
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 37 / 53
Recoverability Types of Recoverability
Maintaining Serialisability and Recoverability
two-phase locking (2PL)
conflict baseduses locks to prevent problemscommon technique
time-stamping
add a timestamp to each objectwrite sets timestamp to that of transactionmay only read or write objects with earlier timestampabort when object has new timestampcommon technique
optimistic concurrency control
do nothing until commitat commit, inspect history for problemsgood if few conflicts
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 38 / 53
2PL Basic 2PL
The 2PL Protocol
1 read locks rl[o], . . . , r[o], . . . , ru[o]
2 write locks wl[o], . . . , w[o], . . . , wu[o]
3 Two phases
i growing phase
ii shrinking phase
4 refuse rli[o] if wlj [o] already heldrefuse wli[o] if rlj [o] or wlj [o] already held
5 rli[o] or wli[o] refused → delay Ti
✲time
✻
no.locksin Hi
bi ei
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 39 / 53
2PL Basic 2PL
Quiz 9: Two Phase Locking (2PL)
Which history is not valid in 2PL?
A
rl1[a107] , r1[a107] , wl1[a107] , w1[a107] , wu1[a107] , ru1[a107]
B
wl1[a107] , wl1[a100] , r1[a107] , w1[a107] , r1[a100] , w1[a100] , wu1[a100] , wu1[a107]
C
wl1[a107] , r1[a107] , w1[a107] , wu1[a107] , wl1[a100] , r1[a100] , w1[a100] , wu1[a100]
D
wl1[a107] , r1[a107] , w1[a107] , wl1[a100] , r1[a100] , wu1[a107] , w1[a100] , wu1[a100]
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 40 / 53
2PL Basic 2PL
Anomaly 1: Lost Update
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1
BEGIN TRANSACTION T2EXEC move cash(34,67,2000.00)
COMMIT TRANSACTION T2
r2[b34] , w2[b34] , r2[b67] , w2[b67] , c2
r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r1[b34] , cash=8900.67,
r2[b34] , cash=8900.67, w1[b34] , cash=18900.67, c1 , w2[b34] , cash=6900.42,
r2[b67] , cash=34005.00, w2[b67] , cash=36005.25, c2
− serialisable + recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 41 / 53
2PL Basic 2PL
Anomaly 1: Lost Update
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
r1[b56] , w1[b56] , r1[b34] , w1[b34] , c1
BEGIN TRANSACTION T2EXEC move cash(34,67,2000.00)
COMMIT TRANSACTION T2
r2[b34] , w2[b34] , r2[b67] , w2[b67] , c2
r1[b56] , cash=94340.45, w1[b56] , cash=84340.45, r1[b34] , cash=8900.67,
r2[b34] , cash=8900.67, lostupdate, c1 , w2[b34] , cash=6900.42,
r2[b67] , cash=34005.00, w2[b67] , cash=36005.25, c2
− serialisable + recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 41 / 53
2PL Basic 2PL
Lost Update Anomaly with 2PL
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
b1 , wl1[b56] , r1[b56] , w1[b56] , wl1[b34] ,
r1[b34] , w1[b34] , c1 , wu1[b56] , wu1[b34]
BEGIN TRANSACTION T2EXEC move cash(34,67,2000.00)
COMMIT TRANSACTION T2
b2 , wl2[b34] , r2[b34] , w2[b34] , wl2[b67] ,
r2[b67] , w2[b67] , c2 , wu2[b34] , wu2[b67]
b1 , wl1[b56] , r1[b56] , w1[b56] , wl1[b34] , r1[b34] , b2 , wl2[b34] , r2[b34] , w1[b34] , c1 ,
wu1[b56] , wu1[b34] , w2[b34] , wl2[b67] , r2[b67] , w2[b67] , c2 , wu2[b34] , wu2[b67]
Lost Update history not permitted by 2PL, since wl2[b34] not granted
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 42 / 53
2PL Basic 2PL
Lost Update Anomaly with 2PL
BEGIN TRANSACTION T1EXEC move cash(56,34,10000.00)
COMMIT TRANSACTION T1
b1 , wl1[b56] , r1[b56] , w1[b56] , wl1[b34] ,
r1[b34] , w1[b34] , c1 , wu1[b56] , wu1[b34]
BEGIN TRANSACTION T2EXEC move cash(34,67,2000.00)
COMMIT TRANSACTION T2
b2 , wl2[b34] , r2[b34] , w2[b34] , wl2[b67] ,
r2[b67] , w2[b67] , c2 , wu2[b34] , wu2[b67]
b1 , wl1[b56] , r1[b56] , w1[b56] , wl1[b34] , r1[b34] , b2 , w1[b34] , c1 , wu1[b56] , wu1[b34] ,
wl2[b34] , r2[b34] , w2[b34] , wl2[b67] , r2[b67] , w2[b67] , c2 , wu2[b34] , wu2[b67]
2PL causes T2 to be delayed
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 42 / 53
2PL Basic 2PL
Why does 2PL Work?
✲time
✻no. locks
bi eibj ej
Hi Hj
two-phase rule → maximum lock period
can re-time history so all operations take place during maximum lock period
CSR since all conflicts prevented during maximum lock period
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 43 / 53
2PL Scheduling
When to lock: Aggressive Scheduler
b1, r1[b56], w1[b56], r1[b34], w1[b34], c1
rl1[b56]
⇓
wl1[b56]
⇓
rl1[b34]
wl1[b56]
⇓
wl1[b34]
wl1[b56]
⇓
wl1[b34]
wl1[b56]
⇓∅⇓
delay taking locks as long as possible
maximises concurrency
might suffer delays later on
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 44 / 53
2PL Scheduling
When to lock: Conservative Scheduler
b2, r2[b34], w2[b34], r2[b67], w2[b67], c2
wl2[b34]
wl2[b67]
⇓
wl2[b34]
wl2[b67]
⇓
wl2[b67]
⇓
wl2[b67]
⇓∅⇓
take locks as soon as possible
removes risks of delays later on
might refuse to start
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 45 / 53
2PL Deadlock Detection
Deadlock Detection: WFG with No Cycle = No Deadlock
Hn b1 r1[b56] w1[b56] b2 r2[b34] w2[b34]
rl1[b56]
⇓
wl1[b56]
⇓
wl1 [b56]
⇓
rl2[b34]
wl1[b56]
⇓
wl2[b34]
wl1[b56]
⇓
WFG(Hn)
T1 T2
rl1[b34]
waits-for graph (WFG)
describes which transactions waits for others
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 46 / 53
2PL Deadlock Detection
Deadlock Detection: WFG with No Cycle = No Deadlock
Hn b1 r1[b56] w1[b56] b2 r2[b34] w2[b34]
rl1[b56]
⇓
wl1[b56]
⇓
wl1 [b56]
⇓
rl2[b34]
wl1[b56]
⇓
wl2[b34]
wl1[b56]
⇓
WFG(Hn)
T1 T2
rl1[b34]
H1 attempts r1[b34] , but is refused since H2 has a write-lock, and so is put on WFG
waits-for graph (WFG)
describes which transactions waits for others
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 46 / 53
2PL Deadlock Detection
Deadlock Detection: WFG with No Cycle = No Deadlock
Hn b1 r1[b56] w1[b56] b2 r2[b34] w2[b34] r2[b67] w2[b67] c2
rl1[b56]
⇓
wl1[b56]
⇓
wl1 [b56]
⇓
rl2[b34]
wl1[b56]
⇓
wl2[b34]
wl1[b56]
⇓
rl2[b67]
wl2[b34]
wl1[b56]
⇓
wl2[b67]
wl2[b34]
wl1[b56]
⇓
wl2 [b67]
wl2 [b34]
wl1 [b56]
⇓
wl1[b56]
⇓
WFG(Hn)
T1 T2
rl1[b34]
H2 can proceed to complete its execution, after which it will have released all its locks
waits-for graph (WFG)
describes which transactions waits for others
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 46 / 53
2PL Deadlock Detection
Deadlock Detection: WFG with No Cycle = No Deadlock
Hn b1 r1[b56] w1[b56] b2 r2[b34] w2[b34] r2[b67] w2[b67] c2 r1[b34] w1[b34] c1
rl1[b56]
⇓
wl1[b56]
⇓
wl1 [b56]
⇓
rl2[b34]
wl1[b56]
⇓
wl2[b34]
wl1[b56]
⇓
rl2[b67]
wl2[b34]
wl1[b56]
⇓
wl2[b67]
wl2[b34]
wl1[b56]
⇓
wl2 [b67]
wl2 [b34]
wl1 [b56]
⇓
wl1[b56]
⇓
rl1[b34]
wl1[b56]
⇓
wl1[b34]
wl1[b56]
⇓
wl1 [b34]
wl1 [b56]
⇓
WFG(Hn)
T1 T2
rl1[b34]
H1 may now proceed to completion
waits-for graph (WFG)
describes which transactions waits for others
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 46 / 53
2PL Deadlock Detection
Deadlock Detection: WFG with Cycle = Deadlock
Hd b1 r1[b56] w1[b56] r1[b34] b2 r2[b34]dead-lock
rl1[b56]
⇓
wl1[b56]
⇓
rl1[b34]
wl1[b56]
⇓
rl1[b34]
wl1[b56]
⇓
rl2[b34]
rl1[b34]
wl1[b56]
⇓
rl2[b34]
rl1[b34]
wl1[b56]
⇓
WFG(Hd)
T1 T2
wl1[b34]
wl2[b34]
Cycle in WFG means DB in a deadlock state, must abort either H1 or H2
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 47 / 53
2PL Deadlock Detection
Quiz 10: Resolving Deadlocks in 2PL
H1 = r1[p1] , r1[p2] , r1[p3] , r1[p4] , r1[p5] , r1[p6]
H2 = r2[p5] , w2[p5] , r2[p1] , w2[p1]
H3 = r3[p6] , w3[p6] , r3[p2] , w3[p2]
H4 = r4[p4] , r4[p5] , r4[p6]
Suppose the transactions above have reached the following deadlock state
Hq = r1[p1] , r1[p2] , r1[p3] , r1[p4] , r2[p5] , w2[p5] , r2[p1] ,
r3[p6] , w3[p6] , r3[p2] , r4[p4]
Which transaction should be aborted?
A
H1
B
H2
C
H3
D
H4
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 48 / 53
2PL Deadlock Detection
Example WFG
WFG(Hq)
T1 T2
rl1[p5]
wl2[p1]
T3
wl3[p2]
T4
rl4[p5]
Hq = r1[p1] , r1[p2] , r1[p3] , r1[p4] , r2[p5] , w2[p5] , r2[p1] ,
r3[p6] , w3[p6] , r3[p2] , r4[p4]
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 49 / 53
2PL Deadlock Detection
Worksheet: Deadlocks
H1 = w1[o1] , r1[o2] , r1[o4]
H2 = r2[o3] , r2[o2] , r2[o1]
H3 = r3[o4] , w3[o4] , r3[o3] , w3[o3]
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 50 / 53
2PL Deadlock Detection
Conservative Locking
✲time
✻no. locks
in Hi
bi ei
Conservative Locking
prevents deadlock
when to release locks problem
not recoverable
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 51 / 53
2PL Deadlock Detection
Strict Locking
✲time
✻
no.locksin Hi
bi ei
❄
only release readlocks before ei
strict locking
✲time
✻
no.locksin Hi
bi eistrong strict locking
Strict Locking
prevents write locks being released before transaction end
allows deadlocks
no dirty reads/writes → recoverable
Strong Strict Locking
In addition to strict locking properties
prevents read locks being released before transaction end
simple to implement
suitable for distributed transactions (using atomic commit)P.J. Mc.Brien (Computing, Imperial) Concurrency Control 52 / 53
Isolation Levels Need for Serialisability?
Transaction Isolation Levels
Do we always need ACID properties?
BEGIN TRANSACTION T3SELECT DISTINCT noFROM movementWHERE amount>=1000.00
COMMIT TRANSACTION T3
Some transactions only need ‘approximate’ resultse.g. Management overviewe.g. Estimates
May execute these transactions at a ‘lower’ level of concurrency controlSQL allows you to vary the level of concurrency control
P.J. Mc.Brien (Computing, Imperial) Concurrency Control 53 / 53