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

Transcription

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

2 Transactions ACID properties Transactions: 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 (Imperial College London) Concurrency Control 2 / 1

3 Transactions ACID properties DBMS Architecture disc transaction manager result reject delay scheduler execute begin read write abort commit recovery manager flush read write read fetch buffer write memory manager write read data manager P.J. M c.brien (Imperial College London) Concurrency Control 3 / 1

4 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 A history of transaction T n consists of 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 1 b n begin transaction (only given if necessary for discussion) 2 Various read operations on objects r n[o j] and write operations r 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 (Imperial College London) Concurrency Control 4 / 1

5 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 A history of transaction T n consists of 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 1 b n begin transaction (only given if necessary for discussion) 2 Various read operations on objects r n[o j] and write operations r 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 (Imperial College London) Concurrency Control 5 / 1

6 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 (Imperial College London) Concurrency Control 6 / 1

7 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 (Imperial College London) Concurrency Control 7 / 1

8 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 (Imperial College London) Concurrency Control 8 / 1

9 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 (Imperial College London) Concurrency Control 9 / 1

10 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 (Imperial College London) Concurrency Control 10 / 1

11 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= 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 (Imperial College London) Concurrency Control 11 / 1

12 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 (Imperial College London) Concurrency Control 12 / 1

13 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 (Imperial College London) Concurrency Control 13 / 1

14 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 (Imperial College London) Concurrency Control 14 / 1

15 Concurrency Anomalies Quiz 5: Anomalies (2) 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 (Imperial College London) Concurrency Control 15 / 1

16 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 (Imperial College London) Concurrency Control 16 / 1

17 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 (Imperial College London) Concurrency Control 17 / 1

18 Concurrency Anomalies Anomaly 5: Phantom reads BEGIN TRANSACTION T7 UPDATE account SET rate=rate+0.25 WHERE type= deposit AND rate<5.5 UPDATE account SET rate=rate+0.25 WHERE type= deposit COMMIT TRANSACTION T7 BEGIN TRANSACTION T8 INSERT INTO account VALUES (126, deposit, Boyd,M.,5.25,34) COMMIT TRANSACTION T8 r 7[a 101],rate=5.25, w 7[a 101],rate=5.50, r 7[a 119],rate=5.50, ins 8[a 126],rate=5.25, c 8, r 7[a 101],rate=5.50, w 7[a 101],rate=5.75, r 7[a 119],rate=5.50, w 7[a 119],rate=5.75, r 7[a 126],rate=5.25, w 7[a 126],rate=5.50, c 7 serialisable + recoverable P.J. M c.brien (Imperial College London) Concurrency Control 18 / 1

19 Concurrency Anomalies Movement and Account Tables 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 P.J. M c.brien (Imperial College London) Concurrency Control 19 / 1

20 Concurrency Anomalies Anomaly 6: Write skew BEGIN TRANSACTION T9 INSERT INTO movement SELECT 1011,w account.no, , 21-jan-1999 FROM movement NATURAL JOIN account JOIN account w account ON account.cname=w account.cname WHERE w account.no=101 GROUP BY w account.no HAVING SUM(amount)>= ; COMMIT TRANSACTION T9 BEGIN TRANSACTION T10 INSERT INTO movement SELECT 1012,w account.no, , 21-jan-1999 FROM movement NATURAL JOIN account JOIN account w account ON account.cname=w account.cname WHERE w account.no=100 GROUP BY w account.no HAVING SUM(amount)>= ; COMMIT TRANSACTION T10 r 9[a 101], r 9[a 100], r 9[m 1000], r 9[m 1001], r 9[m 1002], r 9[m 1006], r 9[m 1008], r 10[a 100], r 10[a 101], r 10[m 1000], r 10[m 1001], r 10[m 1002], r 10[m 1006], r 10[m 1008], ins 9[m 1011], ins 10[m 1012], c 9, c 10 note the conflicts r 9[Match(101)] ins 10[m 1012] r 10[Match(100)] ins 9[m 1011] P.J. M c.brien (Imperial College London) Concurrency Control 20 / 1

21 Concurrency Anomalies Anomaly 6: Write skew BEGIN TRANSACTION T9 INSERT INTO movement SELECT 1011,w account.no, , 21-jan-1999 FROM movement NATURAL JOIN account JOIN account w account ON account.cname=w account.cname WHERE w account.no=101 GROUP BY w account.no HAVING SUM(amount)>= ; COMMIT TRANSACTION T9 BEGIN TRANSACTION T10 INSERT INTO movement SELECT 1012,w account.no, , 21-jan-1999 FROM movement NATURAL JOIN account JOIN account w account ON account.cname=w account.cname WHERE w account.no=100 GROUP BY w account.no HAVING SUM(amount)>= ; COMMIT TRANSACTION T10 r 9[Match(101)], r 10[Match(100)], ins 9[m 1011], ins 10[m 1012], c 9, c 10 note the conflicts r 9[Match(101)] ins 10[m 1012] r 10[Match(100)] ins 9[m 1011] P.J. M c.brien (Imperial College London) Concurrency Control 20 / 1

22 Concurrency Anomalies Worksheet: Anomalies P.J. M c.brien (Imperial College London) Concurrency Control 21 / 1

23 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 (Imperial College London) Concurrency Control 22 / 1

24 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 (Imperial College London) Concurrency Control 23 / 1

25 Serialisability View Equivalence & View Serialisable Want database to end up in the same final state as if serial execution had occurred View Equivalence Two histories H i,h j will leave the database in the same final state if, at each commit 1 H i,h j have same set of operations 2 w t[o] r s[o] in both H i,h j or in neither 3 Last committed write on o is w t[o] in both H i,h j or in neither If the above are met, we say the histories are view equivalent H i V E H j View Serialisable Histories a history H is view serialisable (VSR) if C(H) V E a serial history P.J. M c.brien (Imperial College London) Concurrency Control 24 / 1

26 Serialisability Testing for View Equivalence 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 H 2, H 1, H 4 = r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2, r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1, r 4[b 56], r 4[b 34], r 4[b 67], c 4 1 H cp and H 2, H 1, H 4 same set of operations 2 reads are w 2[b 34] r 1[b 34], w 2[b 67] r 4[b 67], reads are w 1[b 34] r 4[b 34], w 1[b 56] r 4[b 56] 3 last committed writes are w 1[b 34], w 1[b 56], and w 2[b 67] H 2, H 1, H 4 V E H cp H cp VSR P.J. M c.brien (Imperial College London) Concurrency Control 25 / 1

27 Serialisability r 2[b 34] w 1[b 34] T1 writes after T2 reads in H x P.J. M c.brien (Imperial College London) Concurrency Control 26 / 1 Conflicts: Potential For Problems Difficult to test for VSR at runtime: need something easier to test at runtime conflict A conflict occurs when there is a interaction between two transactions r x[o] and w y[o] are in H where x y or conflicts w x[o] and w y[o] are in H where x y 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

28 Serialisability Quiz 6: 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 (Imperial College London) Concurrency Control 27 / 1

29 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. CSR VSR P.J. M c.brien (Imperial College London) Concurrency Control 28 / 1

30 Serialisability Testing for Conflict Equivalence 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 H 2, H 1, H 4 = r 2[b 34], w 2[b 34], r 2[b 67], w 2[b 67], c 2, r 1[b 56], w 1[b 56], r 1[b 34], w 1[b 34], c 1, r 4[b 56], r 4[b 34], r 4[b 67], c 4 1 H cp and H 2, H 1, H 4 contain the same set of operations 2 conflicting pairs are w 2[b 34] r 1[b 34], w 2[b 67] r 4[b 67], w 1[b 34] r 4[b 34], w 1[b 56] r 4[b 56] 3 H 2, H 1, H 4 CE H cp H cp CSR P.J. M c.brien (Imperial College London) Concurrency Control 29 / 1

31 Serialisability 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 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 2[b 67] r 4[b 67], w 1[b 34] r 4[b 34], w 1[b 56] r 4[b 56] Then serialisation graph is T 2 T 1 T 4 SG(H cp) is acyclic, therefore H cp is CSR P.J. M c.brien (Imperial College London) Concurrency Control 30 / 1

32 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 (Imperial College London) Concurrency Control 31 / 1

33 Recoverability Definition 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 (Imperial College London) Concurrency Control 32 / 1

34 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 (Imperial College London) Concurrency Control 33 / 1

35 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 (Imperial College London) Concurrency Control 34 / 1

36 Recoverability Types of Recoverability Quiz 7: 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 (Imperial College London) Concurrency Control 35 / 1

37 Recoverability Types of Recoverability Worksheet: Serialisabilty and Recoverability P.J. M c.brien (Imperial College London) Concurrency Control 36 / 1

38 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 (Imperial College London) Concurrency Control 37 / 1

39 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 (Imperial College London) Concurrency Control 38 / 1

40 2PL Basic 2PL Quiz 8: 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 (Imperial College London) Concurrency Control 39 / 1

41 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 (Imperial College London) Concurrency Control 40 / 1

42 2PL Inserts in 2PL Anomaly 5: Phantom reads BEGIN TRANSACTION T7 UPDATE account SET rate=rate+0.25 WHERE type= deposit AND rate<5.5 UPDATE account SET rate=rate+0.25 WHERE type= deposit COMMIT TRANSACTION T7 BEGIN TRANSACTION T8 INSERT INTO account VALUES (126, deposit, Boyd,M.,5.25,34) COMMIT TRANSACTION T8 r 7[a 101],rate=5.25, w 7[a 101],rate=5.50, r 7[a 119],rate=5.50, ins 8[a 126],rate=5.25, c 8, r 7[a 101],rate=5.50, w 7[a 101],rate=5.75, r 7[a 119],rate=5.50, w 7[a 119],rate=5.75, r 7[a 126],rate=5.25, w 7[a 126],rate=5.50, c 7 serialisable + recoverable P.J. M c.brien (Imperial College London) Concurrency Control 41 / 1

43 2PL Inserts in 2PL Naive 2PL of Insert rl 7[a 101] wl 7[a 101] rl 7[a 119] wl 7[a 101] rl 7[a 119] wl 7[a 101] wl 8[a 126] rl 7[a 119] wl 7[a 101] wl 8[a 126] rl 7[a 119] wl 7[a 101] rl 7[a 119] wl 7[a 101] b 7, r 7 [a 101 ], w 7 [a 101 ], r 7 [a 119 ], b 8, ins 8[a 126], c 8,... rl 7[a 119] wl 7[a 101] rl 7[a 119] wl 7[a 101] wl 7[a 119] wl 7[a 101] rl 7[a 126] wl 7[a 119] wl 7[a 101] wl 7[a 126] wl 7[a 119] wl 7[a 101] wl 7[a 126] wl 7[a 119] wl 7[a 101]... r 7 [a 101 ], w 7 [a 101 ], r 7 [a 119 ], w 7 [a 119 ], r 7 [a 126 ], w 7 [a 126 ], c 7 What is being locked? objects a 101 and a 119? predicate type= deposit AND rate<5.5 P.J. M c.brien (Imperial College London) Concurrency Control 42 / 1

44 2PL Inserts in 2PL Solution 1: EOF Marker Problem with inserts and phantom reads is due to changing size of file Introduce end of file (EOF) marker Read lock EOF when performing a scan of the file H 7 uses rl 7[b EOF] Insert lock when inserting new records H 8 uses il 8[b EOF] Conflict arises when both insert lock and read lock are requested at same time Can produce needless conflicts P.J. M c.brien (Imperial College London) Concurrency Control 43 / 1

45 2PL Inserts in 2PL Solution 2: Predicate Locking P 1 : σ type=deposit rate 5.50 (account) P 2 : σ no=126 type=deposit cname=boyd,m. rate=5.25 branch=34 (account) P 3 : σ type=deposit (account) rl 7 [P 1 ] wl 7 [a 101 ] rl 7 [P 1 ] wl 7 [a 101 ] rl 7 [P 1 ] wl 7 [a 101 ] rl 7 [P 1 ] wl 8 [P 2 ] wl 7 [a 101 ] rl 7 [P 3 ] wl 7 [a 101 ] rl 7 [P 3 ] wl 7 [a 101 ] rl 7 [P 3 ] b 7, r 7 [a 101 ], w 7 [a 101 ], r 7 [a 119 ], b 8, r 7 [a 101 ], w 7 [a 101 ],... wl 7 [a 119 ] wl 7 [a 101 ] rl 7 [P 3 ] wl 7 [a 119 ] wl 7 [a 101 ] rl 7 [P 3 ] wl 7 [a 126 ] wl 7 [a 119 ] wl 7 [a 101 ] rl 7 [P 3 ] wl 7 [a 126 ] wl 7 [a 119 ] wl 7 [a 101 ] rl 7 [P 3 ] wl 8 [P 2 ] wl 8 [P 2 ]... r 7 [a 119 ], w 7 [a 119 ], r 7 [a 126 ], w 7 [a 126 ], c 7, ins 8[a 126], c 8 lock the predicate that the transaction uses difficult to implement P.J. M c.brien (Imperial College London) Concurrency Control 44 / 1

46 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 (Imperial College London) Concurrency Control 45 / 1

47 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 (Imperial College London) Concurrency Control 46 / 1

48 2PL Scheduling Aggressive Schedulers Might Deadlock 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 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 ] b 2, r 2 [b 34 ], w 2 [b 34 ], r 2 [b 67 ], w 2 [b 67 ], c 2 rl 2 [b 34 ] rl 2 [b 34 ] rl 1 [b 34 ] rl 1 [b 34 ] rl 1 [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 ] b 1, r 1 [b 56 ], w 1 [b 56 ], r 1 [b 34 ], b 2, r 2 [b 34 ], deadlock P.J. M c.brien (Imperial College London) Concurrency Control 47 / 1

49 2PL 2PL Implementation Issues to Address 1 deadlock 2 shrinking requires advanced knowledge of what the remainder of the history will contain 3 the recoverability of transactions is not ensured (commit with dirty reads allowed) 4 livelock P.J. M c.brien (Imperial College London) Concurrency Control 48 / 1

50 2PL 2PL Implementation 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 ] 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 rl 1 [b 34 ] H 1 H 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 (Imperial College London) Concurrency Control 49 / 1

51 2PL 2PL Implementation 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 ] 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 H 1 waits-for graph (WFG) describes which transactions waits for others P.J. M c.brien (Imperial College London) Concurrency Control 49 / 1

52 2PL 2PL Implementation 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] b 1 r 1[b 56] w 1[b 56] r 1[b 34] b 2 r deadlock 2[b 34] wl 1[b 34] H 1 H 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 (Imperial College London) Concurrency Control 50 / 1

53 2PL 2PL Implementation Quiz 9: 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 d = 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 (Imperial College London) Concurrency Control 51 / 1

54 2PL 2PL Implementation Quiz 10: Avoiding Deadlocks in 2PL Which scheduling method for 2PL avoids deadlocks? A Gain all the locks for a transaction at the start, and then release locks as they are no longer required during transaction execution. B Gain locks only as required during transaction execution, and release locks only at the end of the transaction. C Gain locks only as required during transaction execution, and release locks as soon as possible. D Gain locks only as required during transaction execution, except if a read lock is being obtained, first check to see if the transaction will later require a write lock on the same object, and if so, obtain a write lock. Release locks as soon as possible. P.J. M c.brien (Imperial College London) Concurrency Control 52 / 1

55 2PL 2PL Implementation Conservative Locking no. locks in H i b i e i time prevents deadlock release problem harder still not recoverable P.J. M c.brien (Imperial College London) Concurrency Control 53 / 1

56 2PL 2PL Implementation Strict Locking no. locks in H i only release read locks before e i no. locks in H i b i strict locking e i time b i strong strict locking e i time strict locking prevents write locks being released before transaction end recoverable allows deadlocks strong strict locking means no locks released before end no problem determining when to release P.J. M c.brien (Imperial College London) Concurrency Control 54 / 1

57 2PL 2PL Implementation Livelock Prevention livelocks caused by transaction waiting indefinite time for lock associate priority with transaction increase priority with time at some point transaction must reach maximum priority P.J. M c.brien (Imperial College London) Concurrency Control 55 / 1

58 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 (Imperial College London) Concurrency Control 56 / 1

59 Isolation Levels SQL Isolation Levels SQL: READ UNCOMMITTED Set by executing SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED The weakest level, only prevents dirty writes Allows transactions to read uncommitted data Hence allows Dirty reads Anomaly Possible Dirty Write N Dirty Read Y Lost Update Y Inconsistent Analysis Y Phantom Y Write Skew Y P.J. M c.brien (Imperial College London) Concurrency Control 57 / 1

60 Isolation Levels SQL Isolation Levels SQL: READ COMMITTED Allows transactions to only read committed data Recoverable; but may suffer inconsistent analysis Anomaly Possible Dirty Write N Dirty Read N Lost Update Y Inconsistent Analysis Y Phantom Y Write Skew Y P.J. M c.brien (Imperial College London) Concurrency Control 58 / 1

61 Isolation Levels SQL Isolation Levels SQL: SNAPSHOT Transactions behave as if read committed version of data at start of transaction, and write all data at end of transaction Not standard SQL. Available in SQL-Server 2005 Postgres SERIALIZABLE is infact SNAPSHOT Anomaly Possible Dirty Write N Dirty Read N Lost Update N Inconsistent Analysis N Phantom N Write Skew Y P.J. M c.brien (Imperial College London) Concurrency Control 59 / 1

62 Isolation Levels SQL Isolation Levels SQL: REPEATABLE READ Allows inserts to tables already read Allows phantom reads Prevents write skew Anomaly Possible Dirty Write N Dirty Read N Lost Update N Inconsistent Analysis N Phantom Y Write Skew N P.J. M c.brien (Imperial College London) Concurrency Control 60 / 1

63 Isolation Levels SQL Isolation Levels SQL: SERIALIZABLE Execution equivalent to a serial execution no anomalies of any kind (not just those listed) Anomaly Possible Dirty Write N Dirty Read N Lost Update N Inconsistent Analysis N Phantom N Write Skew N P.J. M c.brien (Imperial College London) Concurrency Control 61 / 1

64 Isolation Levels SQL Isolation Levels THE END Revision Review worksheets, coursework and exercises in notes Exam similar to exams of previous years Content of the course is what was presented in the lectures Going Further... Project (Object-Relational Mapping, Data and Knowledge Integration, Managing BigData) PhD P.J. M c.brien (Imperial College London) Concurrency Control 62 / 1