Concurrency Control. Peter M c.brien. Dept. of Computing, Imperial College London. P.J. M c.brien (Computing, Imperial) Concurrency Control 1 / 53

Size: px

Start display at page:

Download "Concurrency Control. Peter M c.brien. Dept. of Computing, Imperial College London. P.J. M c.brien (Computing, Imperial) Concurrency Control 1 / 53"

Helena Flynn
5 years ago
Views:

1 Concurrency Control Peter M c.brien Dept. of Computing, Imperial College London P.J. M c.brien (Computing, Imperial) Concurrency Control 1 / 53

2 Transactions ACID properties Transactions: ACID properties ACID properties database management systems (DBMS) implements indivisible tasks called transactions Atomicity all or nothing Consistency consistent before consistent after Isolation independent of any other transaction Durability completed transaction are durable BEGIN TRANSACTION UPDATE branch SET cash=cash WHERE sortcode=56 UPDATE branch SET cash=cash WHERE sortcode=34 COMMIT TRANSACTION Note that if total cash is 137, before the transaction, then it will be the same after the transaction. P.J. M c.brien (Computing, Imperial) Concurrency Control 2 / 53

3 Transactions ACID properties Example Data branch sortcode bname cash 56 Wimbledon Goodge St Strand movement mid no amount tdate /1/ /1/ /1/ /1/ /1/ /1/ /1/ /1/ /1/1999 account no type cname rate? sortcode 100 current McBrien, P. NULL deposit McBrien, P current Boyd, M. NULL current Poulovassilis, A. NULL deposit Poulovassilis, A 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. M c.brien (Computing, Imperial) Concurrency Control 3 / 53

4 Transactions ACID properties Transaction Properties: Atomicity BEGIN TRANSACTION UPDATE branch SET c a s h=cash WHERE sortcode=56 CRASH Suppose that the system crashes half way through processing a cash transfer, and the first 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 the change to branch 56 P.J. M c.brien (Computing, Imperial) Concurrency Control 4 / 53

5 Transactions ACID properties Transaction Properties: Consistency BEGIN TRANSACTION DELETE FROM branch WHERE sortcode=56 INSERT INTO account VALUES (100, Smith, J, deposit,5.00,34) END TRANSACTION Suppose that a user deletes branch with sortcode 56, and inserts a deposit account number 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, and it has two records for account number 100, with different details for the account A DBMS implementing Consistency of transactions would forbid both of these changes to the database P.J. M c.brien (Computing, Imperial) Concurrency Control 5 / 53

6 Transactions ACID properties Transaction Properties: Isolation BEGIN TRANSACTION UPDATE branch SET c a s h=cash WHERE sortcode=56 BEGIN TRANSACTION UPDATE branch SET cash=cash WHERE sortcode=34 END TRANSACTION SELECT SUM(cash) AS net cash FROM branch END TRANSACTION Suppose that the system sums the cash in the bank in one transaction, half way through 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 transactions always report results based on the values of committed transactions P.J. M c.brien (Computing, Imperial) Concurrency Control 6 / 53

7 Transactions ACID properties Transaction Properties: Durability BEGIN TRANSACTION UPDATE branch SET c a s h=cash WHERE sortcode=56 UPDATE branch SET cash=cash WHERE sortcode=34 END TRANSACTION CRASH Suppose that the system crashes after informing the user that it has committed the transfer 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 complete the change to branch 34 (or alternatively never inform a user of commitment with writing the results to disc). P.J. M c.brien (Computing, Imperial) Concurrency Control 7 / 53

8 Transactions ACID properties SQL Conversion to Histories BEGIN TRANSACTION T1 UPDATE branch SET cash=cash WHERE sortcode=56 UPDATE branch SET cash=cash WHERE sortcode=34 COMMIT TRANSACTION T1 branch sortcode bname cash 56 Wimbledon Goodge St Strand H 1 = r 1 [b 56 ],cash= , w 1 [b 56 ],cash= , r 1 [b 34 ],cash= , w 1 [b 34 ],cash= , c 1 history of transaction T n 1 Begin transaction b n (only given if necessary for discussion) 2 Various read operations on objects r n[o j] and write operations w n[o j] 3 Either c n for the commitment of the transaction, or a n for the abort of the transaction P.J. M c.brien (Computing, Imperial) Concurrency Control 8 / 53

9 Transactions ACID properties SQL Conversion to Histories BEGIN TRANSACTION T2 UPDATE branch SET cash=cash WHERE sortcode=34 UPDATE branch SET cash=cash WHERE sortcode=67 COMMIT TRANSACTION T2 branch sortcode bname cash 56 Wimbledon Goodge St Strand H 2 = r 2 [b 34 ],cash= , w 2 [b 34 ],cash= , r 2 [b 67 ],cash= , w 2 [b 67 ],cash= , c 2 history of transaction T n 1 Begin transaction b n (only given if necessary for discussion) 2 Various read operations on objects r n[o j] and write operations w n[o j] 3 Either c n for the commitment of the transaction, or a n for the abort of the transaction P.J. M c.brien (Computing, Imperial) Concurrency Control 9 / 53

10 Concurrency Definition Concurrent Execution Concurrent Execution of Transactions Interleaving of several transaction histories Order of operations within each history preserved H 1 = r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1 H 2 = r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2 Some possible concurrent executions are H x = r 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, w 2 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2 H y = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2, c 1 H z = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, r 2 [b 67 ], w 2 [b 67 ], c 2 P.J. M c.brien (Computing, Imperial) Concurrency Control 10 / 53

11 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 as some serial execution of those same transactions recoverability No transaction commits depending on data that has been produced by another transaction that has yet to commit P.J. M c.brien (Computing, Imperial) Concurrency Control 11 / 53

12 Concurrency Definition Quiz 1: Serialisability and Recoverability (1) H x = r 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, w 2 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2 Is H x A Not Serialisable, Not Recoverable B Not Serialisable, Recoverable C Serialisable, Not Recoverable D Serialisable, Recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 12 / 53

13 Concurrency Definition Quiz 2: Serialisability and Recoverability (2) H y = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2, c 1 Is H y A Not Serialisable, Not Recoverable B Not Serialisable, Recoverable C Serialisable, Not Recoverable D Serialisable, Recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 13 / 53

14 Concurrency Definition Quiz 3: Serialisability and Recoverability (3) H z = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, r 2 [b 67 ], w 2 [b 67 ], c 2 Is H z A Not Serialisable, Not Recoverable B Not Serialisable, Recoverable C Serialisable, Not Recoverable D Serialisable, Recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 14 / 53

15 Concurrency Anomalies Anomaly 1: Lost Update BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T2 EXEC move cash(34,67, ) COMMIT TRANSACTION T2 r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1 r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2 r 1[b 56],cash= , w 1[b 56],cash= , r 1[b 34],cash= , r 2[b 34],cash= , w 1[b 34],cash= , c 1, w 2[b 34],cash= , r 2[b 67],cash= , w 2[b 67],cash= , c 2 serialisable + recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 15 / 53

16 Concurrency Anomalies Anomaly 1: Lost Update BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T2 EXEC move cash(34,67, ) COMMIT TRANSACTION T2 r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1 r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2 r 1[b 56],cash= , w 1[b 56],cash= , r 1[b 34],cash= , r 2[b 34],cash= ,lostupdate, c 1, w 2[b 34],cash= , r 2[b 67],cash= , w 2[b 67],cash= , c 2 serialisable + recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 15 / 53

17 Concurrency Anomalies Anomaly 2: Inconsistent analysis BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T4 SELECT SUM(cash) FROM branch COMMIT TRANSACTION T4 r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1 H 4 = r 4[b 56], r 4[b 34], r 4[b 67], c 4 r 1[b 56],cash= , w 1[b 56],cash= , r 4[b 56],cash= , r 4[b 34],cash= , r 4[b 67],cash= , r 1[b 34],cash= , w 1[b 34],cash= , c 1, c 4 serialisable + recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 16 / 53

18 Concurrency Anomalies Anomaly 3: Dirty Reads BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T2 EXEC move cash(34,67, ) COMMIT TRANSACTION T2 r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1 r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2 r 1[b 56],cash= , w 1[b 56],cash= , r 2[b 34],cash= , w 2[b 34],cash= , r 1[b 34],cash= , w 1[b 34],cash= , c 1, r 2[b 67],cash= , w 2[b 67],cash= , a 2 + serialisable recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 17 / 53

19 Concurrency Anomalies Quiz 4: Anomalies (1) H x = r 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, w 2 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2 Which anomaly does H x suffer? A None C Inconsistent Analysis B Lost Update D Dirty Read P.J. M c.brien (Computing, Imperial) Concurrency Control 18 / 53

20 Concurrency Anomalies Quiz 5: Anomalies (2) H y = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2, c 1 Which anomaly does H y suffer? A None C Inconsistent Analysis B Lost Update D Dirty Read P.J. M c.brien (Computing, Imperial) Concurrency Control 19 / 53

21 Concurrency Anomalies Quiz 6: Anomalies (3) H z = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, r 2 [b 67 ], w 2 [b 67 ], c 2 Which anomaly does H z suffer? A None C Inconsistent Analysis B Lost Update D Dirty Read P.J. M c.brien (Computing, Imperial) Concurrency Control 20 / 53

22 Concurrency Anomalies Patterns of operations associated with Anomalies Anomaly Pattern Dirty Write w 1[o] w 2[o] e 1 Dirty Read w 1[o] r 2[o] e 1 Inconsistent Analysis r 1[o a] w 2[o a], w 2[o b ] r 1[o b ] Lost Update r 1[o] w 2[o] w 1[o] Notation e i means either c i or a i occurring op a op b mean op a occurs before op b in a history P.J. M c.brien (Computing, Imperial) Concurrency Control 21 / 53

23 Concurrency Anomalies Worksheet: Anomalies rental charge H 1 = r 1[d 1000], w 1[d 1000], r 1[d 1001], w 1[d 1001], r 1[d 1002], w 1[d 1002] transfer charge H 2 = r 2[d 1000], w 2[d 1000], r 2[d 1002], w 2[d 1002] total charge H 3 = r 3[d 1000], r 3[d 1001], r 3[d 1002] P.J. M c.brien (Computing, Imperial) Concurrency Control 22 / 53

24 Concurrency Anomalies Account Table account no type cname rate? sortcode 100 current McBrien, P. NULL deposit McBrien, P current Boyd, M. NULL current Poulovassilis, A. NULL deposit Poulovassilis, A current Bailey, J. NULL 56 P.J. M c.brien (Computing, Imperial) Concurrency Control 23 / 53

25 Concurrency Anomalies Anomaly 4: Dirty Writes BEGIN TRANSACTION T5 UPDATE account SET rate=5.5 WHERE type= deposit COMMIT TRANSACTION T5 BEGIN TRANSACTION T6 UPDATE account SET rate=6.0 WHERE type= deposit COMMIT TRANSACTION T6 H 5 = w 5[a 101],rate=5.5, w 5[a 119],rate=5.5, c 5 H 6 = w 6[a 101],rate=6.0, w 6[a 119],rate=6.0, c 6 w 6[a 101],rate=6.0, w 5[a 101],rate=5.5, w 5[a 119],rate=5.5, w 6[a 119],rate=6.0, c 5, c 6 serialisable + recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 24 / 53

26 Serialisability Serialisable Transaction Execution Solve anomalies H serial execution Only interested in the committed projection H c = r 1[b 56], r 2[b 34], w 2[b 34], r 3[m 1000], r 3[m 1001], r 3[m 1002], w 1[b 56], r 4[b 56], r 3[m 1003], r 3[m 1004], r 3[m 1005], r 1[b 34], a 3, w 1[b 34], c 1, r 4[b 34], C(H c) = r 1[b 56], r 2[b 34], w 2[b 34], w 1[b 56], r 4[b 56], r 1[b 34], w 1[b 34], c 1, r 4[b 34], r 2[b 67], w 2[b 67], c 2, r 4[b 67], c 4 r 2[b 67], w 2[b 67], c 2, r 4[b 67], c 4 P.J. M c.brien (Computing, Imperial) Concurrency Control 25 / 53

27 Serialisability Possible Serial Equivalents Hcp = r 1 [b 56 ], r 2 [b 34 ], w 2 [b 34 ], w 1 [b 56 ], r 4 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, r 4 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2, r 4 [b 67 ], c 4 H 1, H 2, H 4 H 1, H 4, H 2 H 2, H 1, H 4 H 2, H 4, H 1 H 4, H 1, H 2 H 4, H 2, H 1 how to determine that histories are equivalent? how to check this during execution? P.J. M c.brien (Computing, Imperial) Concurrency Control 26 / 53

28 Serialisability Conflicts: Potential For Problems conflict A conflict occurs when there is an interaction between two transactions r x[o] and w y[o] are in H where x y or w x[o] and w y[o] are in H where x y Only consider pairs where there is no third operation rw z[o] between the pair of operations that conflicts with both conflicts H x = r 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, w 2 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2 H y = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2, c 1 H z = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, r 2 [b 67 ], w 2 [b 67 ], c 2 Conflicts w 2[b 34] r 1[b 34] T1 reads from T2 in H y,h z w 1[b 34] w 2[b 34] T2 writes over T1 in H x r 2[b 34] w 1[b 34] T1 writes after T2 reads in H x P.J. M c.brien (Computing, Imperial) Concurrency Control 27 / 53

29 Serialisability Quiz 7: Conflicts H w = r 2 [a 100 ], w 2 [a 100 ], r 2 [a 107 ], r 1 [a 119 ], w 1 [a 119 ], r 1 [a 107 ], w 1 [a 107 ], c 1, w 2 [a 107 ], c 2 Which of the following is not a conflict in H w? A r 2[a 107] r 1[a 107] C r 1[a 107] w 2[a 107] B r 2[a 107] w 1[a 107] D w 1[a 107] w 2[a 107] P.J. M c.brien (Computing, Imperial) Concurrency Control 28 / 53

30 Serialisability Conflict Equivalence and Conflict Serialisable Conflict Equivalence Two histories H i and H j 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 H x = r 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, w 2 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2 Contains conflicts r 2[b 34] w 1[b 34] and w 1[b 34] w 2[b 34] and so is not conflict equivalence to H 1,H 2 nor H 2,H 1, and hence is not conflict serialisable. P.J. M c.brien (Computing, Imperial) Concurrency Control 29 / 53

31 Serialisability SG(H cp) is acyclic, therefore H cp is CSR. Serialisation order T 2,T 1,T 4 P.J. M c.brien (Computing, Imperial) Concurrency Control 30 / 53 Serialisation Graph Serialisation Graph A serialisation graph SG(H) contains a node for each transaction in H, and an edge T i T j if there is some object o for which a conflict rw i[o] rw j[o] exists in H. If SG(H) is acyclic, then H is conflict serialisable. Demonstrating that a History is CSR Given H cp= r 1[b 56], r 2[b 34], w 2[b 34], w 1[b 56], r 4[b 56], r 1[b 34], w 1[b 34], c 1, r 4[b 34], r 2[b 67], w 2[b 67], c 2, r 4[b 67], c 4 Conflicts are w 2[b 34] r 1[b 34], w 1[b 56] r 4[b 56], w 1[b 34] r 4[b 34], w 2[b 67] r 4[b 67] SG(H c) T 2 T 1 T 4

32 Serialisability Worksheet: Serialisability H 1 = r 1[o 1], w 1[o 1], w 1[o 2], w 1[o 3], c 1 H 2 = r 2[o 2], w 2[o 2], w 2[o 1], c 2 H 3 = r 3[o 1], w 3[o 1], w 3[o 2], c 3 H= r 1[o 1], w 1[o 1], r 2[o 2], w 2[o 2], w 2[o 1], c 2, w 1[o 2], r 3[o 1], w 3[o 1], w 3[o 2], c 3, w 1[o 3], c 1 P.J. M c.brien (Computing, Imperial) Concurrency Control 31 / 53

33 Recoverability Definition Recoverability Serialisability necessary for isolation and consistency of committed transactions Recoverability necessary for isolation and consistency when there are also aborted transactions Recoverable execution A recoverable (RC) history H has no transaction committing before another transaction from which it read Execution avoiding cascading aborts A history which avoids cascading aborts (ACA) does not read from a non-committed transaction Strict execution A strict (ST) history does not read from a non-committed transaction nor write over a non-committed transaction ST ACA RC P.J. M c.brien (Computing, Imperial) Concurrency Control 32 / 53

34 Recoverability Types of Recoverability Non-recoverable executions BEGIN TRANSACTION T1 UPDATE branch SET cash=cash WHERE sortcode=56 UPDATE branch SET cash=cash WHERE sortcode=34 COMMIT TRANSACTION T1 BEGIN TRANSACTION T4 SELECT SUM(cash) FROM branch COMMIT TRANSACTION T4 H 1 = r 1[b 56], w 1[b 56], a 1 H 4 = r 4[b 56], r 4[b 34], r 4[b 67], c 4 H c = r 1 [b 56 ],cash= , w 1 [b 56 ],cash= , r 4 [b 56 ],cash= , r 4 [b 34 ],cash= , r 4 [b 67 ],cash= , c 4, a 1 H c RC P.J. M c.brien (Computing, Imperial) Concurrency Control 33 / 53

35 Recoverability Types of Recoverability Cascading Aborts BEGIN TRANSACTION T1 UPDATE branch SET cash=cash WHERE sortcode=56 UPDATE branch SET cash=cash WHERE sortcode=34 COMMIT TRANSACTION T1 BEGIN TRANSACTION T4 SELECT SUM(cash) FROM branch COMMIT TRANSACTION T4 H 1 = r 1[b 56], w 1[b 56], a 1 H 4 = r 4[b 56], r 4[b 34], r 4[b 67], c 4 H c = r 1 [b 56 ],cash= , w 1 [b 56 ],cash= , r 4 [b 56 ],cash= , r 4 [b 34 ],cash= , r 4 [b 67 ],cash= , a 1, a 4 H c RC H c ACA P.J. M c.brien (Computing, Imperial) Concurrency Control 34 / 53

36 Recoverability Types of Recoverability Strict Execution BEGIN TRANSACTION T5 UPDATE account SET rate=5.5 WHERE type= deposit COMMIT TRANSACTION T5 BEGIN TRANSACTION T6 UPDATE account SET rate=6.0 WHERE type= deposit COMMIT TRANSACTION T6 H 5 = w 5[a 101],rate=5.5, w 5[a 119],rate=5.5, a 5 H 6 = w 6[a 101],rate=6.0, w 6[a 119],rate=6.0, c 6 H c = w 6[a 101],rate=6.0, w 5[a 101],rate=5.5, w 5[a 119],rate=5.5, w 6[a 119],rate=6.0, a 5, c 6 H c ACA H c ST P.J. M c.brien (Computing, Imperial) Concurrency Control 35 / 53

37 Recoverability Types of Recoverability Quiz 8: Recoverability H z = r 2 [b 34 ], w 2 [b 34 ], r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1, r 2 [b 67 ], w 2 [b 67 ], c 2 Which describes the recoverability of H z? A Non-recoverable C Avoids Cascading Aborts B Recoverable D Strict P.J. M c.brien (Computing, Imperial) Concurrency Control 36 / 53

38 Recoverability Types of Recoverability Worksheet: Recoverability H w = r 2[o 1], r 2[o 2], w 2[o 2], r 1[o 2], w 2[o 1], r 2[o 3], c 2, c 1 H x = r 2[o 1], r 2[o 2], w 2[o 1], w 2[o 2], w 1[o 1], w 1[o 2], c 1, r 2[o 3], c 2 H y = r 2[o 1], r 2[o 2], w 2[o 2], r 1[o 2], w 2[o 1], c 1, r 2[o 3], c 2 H z = r 2[o 1], w 1[o 1], r 2[o 2], w 2[o 2], r 2[o 3], c 2, r 1[o 2], w 1[o 2], w 1[o 3], c 1 P.J. M c.brien (Computing, Imperial) Concurrency Control 37 / 53

39 Recoverability Types of Recoverability Maintaining Serialisability and Recoverability two-phase locking (2PL) conflict based uses locks to prevent problems common technique time-stamping add a timestamp to each object write sets timestamp to that of transaction may only read or write objects with earlier timestamp abort when object has new timestamp common technique optimistic concurrency control do nothing until commit at commit, inspect history for problems good if few conflicts P.J. M c.brien (Computing, Imperial) Concurrency Control 38 / 53

40 2PL Basic 2PL The 2PL Protocol 1 read locks rl[o],...,r[o],...,ru[o] 2 write locks wl[o],...,w[o],...,wu[o] no. locks in H i 3 Two phases i growing phase ii shrinking phase 4 refuse rl i[o] if wl j[o] already held refuse wl i[o] if rl j[o] or wl j[o] already held b i e i time 5 rl i[o] or wl i[o] refused delay T i P.J. M c.brien (Computing, Imperial) Concurrency Control 39 / 53

41 2PL Basic 2PL Quiz 9: Two Phase Locking (2PL) Which history is not valid in 2PL? A rl 1[a 107], r 1[a 107], wl 1[a 107], w 1[a 107], wu 1[a 107], ru 1[a 107] B wl 1[a 107], wl 1[a 100], r 1[a 107], w 1[a 107], r 1[a 100], w 1[a 100], wu 1[a 100], wu 1[a 107] C wl 1[a 107], r 1[a 107], w 1[a 107], wu 1[a 107], wl 1[a 100], r 1[a 100], w 1[a 100], wu 1[a 100] D wl 1[a 107], r 1[a 107], w 1[a 107], wl 1[a 100], r 1[a 100], wu 1[a 107], w 1[a 100], wu 1[a 100] P.J. M c.brien (Computing, Imperial) Concurrency Control 40 / 53

42 2PL Basic 2PL Anomaly 1: Lost Update BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T2 EXEC move cash(34,67, ) COMMIT TRANSACTION T2 r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1 r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2 r 1[b 56],cash= , w 1[b 56],cash= , r 1[b 34],cash= , r 2[b 34],cash= , w 1[b 34],cash= , c 1, w 2[b 34],cash= , r 2[b 67],cash= , w 2[b 67],cash= , c 2 serialisable + recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 41 / 53

43 2PL Basic 2PL Anomaly 1: Lost Update BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T2 EXEC move cash(34,67, ) COMMIT TRANSACTION T2 r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1 r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2 r 1[b 56],cash= , w 1[b 56],cash= , r 1[b 34],cash= , r 2[b 34],cash= ,lostupdate, c 1, w 2[b 34],cash= , r 2[b 67],cash= , w 2[b 67],cash= , c 2 serialisable + recoverable P.J. M c.brien (Computing, Imperial) Concurrency Control 41 / 53

44 2PL Basic 2PL Lost Update Anomaly with 2PL BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T2 EXEC move cash(34,67, ) COMMIT TRANSACTION T2 b 1, wl 1[b 56], r 1[b 56], w 1[b 56], wl 1[b 34], r 1[b 34], w 1[b 34], c 1, wu 1[b 56], wu 1[b 34] b 2, wl 2[b 34], r 2[b 34], w 2[b 34], wl 2[b 67], r 2[b 67], w 2[b 67], c 2, wu 2[b 34], wu 2[b 67] b 1, wl 1[b 56], r 1[b 56], w 1[b 56], wl 1[b 34], r 1[b 34], b 2, wl 2[b 34], r 2[b 34], w 1[b 34], c 1, wu 1[b 56], wu 1[b 34], w 2[b 34], wl 2[b 67], r 2[b 67], w 2[b 67], c 2, wu 2[b 34], wu 2[b 67] Lost Update history not permitted by 2PL, since wl 2[b 34] not granted P.J. M c.brien (Computing, Imperial) Concurrency Control 42 / 53

45 2PL Basic 2PL Lost Update Anomaly with 2PL BEGIN TRANSACTION T1 EXEC move cash(56,34, ) COMMIT TRANSACTION T1 BEGIN TRANSACTION T2 EXEC move cash(34,67, ) COMMIT TRANSACTION T2 b 1, wl 1[b 56], r 1[b 56], w 1[b 56], wl 1[b 34], r 1[b 34], w 1[b 34], c 1, wu 1[b 56], wu 1[b 34] b 2, wl 2[b 34], r 2[b 34], w 2[b 34], wl 2[b 67], r 2[b 67], w 2[b 67], c 2, wu 2[b 34], wu 2[b 67] b 1, wl 1[b 56], r 1[b 56], w 1[b 56], wl 1[b 34], r 1[b 34], b 2, w 1[b 34], c 1, wu 1[b 56], wu 1[b 34], wl 2[b 34], r 2[b 34], w 2[b 34], wl 2[b 67], r 2[b 67], w 2[b 67], c 2, wu 2[b 34], wu 2[b 67] 2PL causes T2 to be delayed P.J. M c.brien (Computing, Imperial) Concurrency Control 42 / 53

46 2PL Basic 2PL Why does 2PL Work? no. locks H i H j b i b j e i e j time 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. M c.brien (Computing, Imperial) Concurrency Control 43 / 53

47 2PL Scheduling When to lock: Aggressive Scheduler rl 1 [b 34 ] wl 1 [b 34 ] wl 1 [b 34 ] rl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] b 1, r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], w 1 [b 34 ], c 1 delay taking locks as long as possible maximises concurrency might suffer delays later on P.J. M c.brien (Computing, Imperial) Concurrency Control 44 / 53

48 2PL Scheduling When to lock: Conservative Scheduler wl 2 [b 34 ] wl 2 [b 34 ] wl 2 [b 67 ] wl 2 [b 67 ] wl 2 [b 67 ] wl 2 [b 67 ] b 2, r 2 [b 34 ], w 2 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2 take locks as soon as possible removes risks of delays later on might refuse to start P.J. M c.brien (Computing, Imperial) Concurrency Control 45 / 53

49 2PL Deadlock Detection Deadlock Detection: WFG with No Cycle = No Deadlock rl 2 [b 34 ] wl 2 [b 34 ] rl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] H n b 1 r 1 [b 56 ] w 1 [b 56 ] b 2 r 2 [b 34 ] w 2 [b 34 ] WFG(H n) rl 1 [b 34 ] T 1 T 2 waits-for graph (WFG) describes which transactions waits for others P.J. M c.brien (Computing, Imperial) Concurrency Control 46 / 53

50 2PL Deadlock Detection Deadlock Detection: WFG with No Cycle = No Deadlock rl 2 [b 34 ] wl 2 [b 34 ] rl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] H n b 1 r 1 [b 56 ] w 1 [b 56 ] b 2 r 2 [b 34 ] w 2 [b 34 ] WFG(H n) rl 1 [b 34 ] T 1 T 2 H 1 attempts r 1[b 34], but is refused since H 2 has a write-lock, and so is put on WFG waits-for graph (WFG) describes which transactions waits for others P.J. M c.brien (Computing, Imperial) Concurrency Control 46 / 53

51 2PL Deadlock Detection Deadlock Detection: WFG with No Cycle = No Deadlock rl 2 [b 67 ] wl 2 [b 67 ] wl 2 [b 67 ] rl 2 [b 34 ] wl 2 [b 34 ] wl 2 [b 34 ] wl 2 [b 34 ] wl 2 [b 34 ] rl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] H n b 1 r 1 [b 56 ] w 1 [b 56 ] b 2 r 2 [b 34 ] w 2 [b 34 ] r 2 [b 67 ] w 2 [b 67 ] c 2 WFG(H n) rl 1 [b 34 ] T 1 T 2 H 2 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. M c.brien (Computing, Imperial) Concurrency Control 46 / 53

52 2PL Deadlock Detection Deadlock Detection: WFG with No Cycle = No Deadlock rl 2 [b 67 ] wl 2 [b 67 ] wl 2 [b 67 ] rl 2 [b 34 ] wl 2 [b 34 ] wl 2 [b 34 ] wl 2 [b 34 ] wl 2 [b 34 ] rl 1 [b 34 ] wl 1 [b 34 ] wl 1 [b 34 ] rl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] wl 1 [b 56 ] H n b 1 r 1 [b 56 ] w 1 [b 56 ] b 2 r 2 [b 34 ] w 2 [b 34 ] r 2 [b 67 ] w 2 [b 67 ] c 2 r 1 [b 34 ] w 1 [b 34 ] c 1 WFG(H n) rl 1 [b 34 ] T 1 T 2 H 1 may now proceed to completion waits-for graph (WFG) describes which transactions waits for others P.J. M c.brien (Computing, Imperial) Concurrency Control 46 / 53

53 2PL Deadlock Detection Deadlock Detection: WFG with Cycle = Deadlock rl 1[b 34] rl 1[b 34] rl 2[b 34] rl 1[b 34] rl 2[b 34] rl 1[b 34] rl 1[b 56] wl 1[b 56] wl 1[b 56] wl 1[b 56] wl 1[b 56] wl 1[b 56] H d b 1 r 1[b 56] w 1[b 56] r 1[b 34] b 2 r deadlock 2[b 34] WFG(H d ) wl 1[b 34] T 1 T 2 wl 2[b 34] Cycle in WFG means DB in a deadlock state, must abort either H 1 or H 2 P.J. M c.brien (Computing, Imperial) Concurrency Control 47 / 53

54 2PL Deadlock Detection Quiz 10: Resolving Deadlocks in 2PL H 1 = r 1[p 1], r 1[p 2], r 1[p 3], r 1[p 4], r 1[p 5], r 1[p 6] H 2 = r 2[p 5], w 2[p 5], r 2[p 1], w 2[p 1] H 3 = r 3[p 6], w 3[p 6], r 3[p 2], w 3[p 2] H 4 = r 4[p 4], r 4[p 5], r 4[p 6] Suppose the transactions above have reached the following deadlock state H q = r 1[p 1], r 1[p 2], r 1[p 3], r 1[p 4], r 2[p 5], w 2[p 5], r 2[p 1], r 3[p 6], w 3[p 6], r 3[p 2], r 4[p 4] Which transaction should be aborted? A B C D H 1 H 2 H 3 H 4 P.J. M c.brien (Computing, Imperial) Concurrency Control 48 / 53

55 2PL Deadlock Detection Example WFG WFG(H q) rl 1[p 5] T 1 T 2 wl 3[p 2] wl 2[p 1] rl 4[p 5] T 3 T 4 H q = r 1[p 1], r 1[p 2], r 1[p 3], r 1[p 4], r 2[p 5], w 2[p 5], r 2[p 1], r 3[p 6], w 3[p 6], r 3[p 2], r 4[p 4] P.J. M c.brien (Computing, Imperial) Concurrency Control 49 / 53

56 2PL Deadlock Detection Worksheet: Deadlocks H 1 = w 1[o 1], r 1[o 2], r 1[o 4] H 2 = r 2[o 3], r 2[o 2], r 2[o 1] H 3 = r 3[o 4], w 3[o 4], r 3[o 3], w 3[o 3] P.J. M c.brien (Computing, Imperial) Concurrency Control 50 / 53

57 2PL Deadlock Detection Conservative Locking no. locks in H i Conservative Locking prevents deadlock when to release locks problem not recoverable b i e i time P.J. M c.brien (Computing, Imperial) Concurrency Control 51 / 53

58 2PL Deadlock Detection Strict Locking no. locks in H i only release read locks before e i no. locks in H i b i strict locking Strict Locking e i time b i strong 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 e i time suitable for distributed transactions (using atomic commit) P.J. M c.brien (Computing, Imperial) Concurrency Control 52 / 53

59 Isolation Levels Need for Serialisability? Transaction Isolation Levels Do we always need ACID properties? BEGIN TRANSACTION T3 SELECT DISTINCT no FROM movement WHERE amount>= COMMIT TRANSACTION T3 Some transactions only need approximate results e.g. Management overview e.g. Estimates May execute these transactions at a lower level of concurrency control SQL allows you to vary the level of concurrency control P.J. M c.brien (Computing, Imperial) Concurrency Control 53 / 53

Concurrency Control. P.J. M c.brien. Imperial College London. P.J. M c.brien (Imperial College London) Concurrency Control 1 / 1

Concurrency Control. P.J. M c.brien. Imperial College London. P.J. M c.brien (Imperial College London) Concurrency Control 1 / 1 Concurrency Control P.J. M c.brien Imperial College London P.J. M c.brien (Imperial College London) Concurrency Control 1 / 1 Transactions ACID properties Transactions: ACID properties database management