1. 1 CSE 480: Database Systems Lecture 24: Concurrency Control

2. 2 Concurrency Control l Reasons for concurrency control –Although serial execution of a set of transactions may be correct, concurrent (interleaved) transactions may be incorrect  Lost Update Problem  Temporary Update (or Dirty Read) Problem  Incorrect Summary Problem  Nonrepeatable read –Database recovery from transaction failure or system crash becomes more complicated if you don’t control the read/write operations performed by the concurrent transactions

3. 3 Lost update problem l Lost Update Problem –When two transactions that update the same database items have their operations interleaved in a way that makes the value of some database item incorrect

4. 4 Temporary Update (Dirty Read) problem l Temporary Update (or Dirty Read) Problem –When one transaction updates a database item and then the transaction fails for some reason –The updated item could be accessed by another transaction

5. 5 Incorrect Summary Problem l Incorrect Summary Problem –If a transaction is calculating an aggregate function while others are updating some of these records, the aggregate function may calculate some values before they are updated and others after they are updated

6. 6 Nonrepeatable Read Problem l Nonrepeatable Read Problem –If a transaction reads the same data item twice and the item is changed by another transaction between the two reads Value of X has changed

7. 7 Transaction Schedule l To analyze the problems with concurrent transactions, we need to examine their transaction schedule –A transaction schedule is an ordering of database operations from various concurrently executing transactions S a : r 1 (X) r 2 (X) w 1 (X) r 1 (Y) w 2 (X) w 1 (Y) S b : r 1 (X) w 1 (X) r 2 (X) w 2 (X) r 1 (Y)

8. 8 Why Study Transaction Schedule? l Characteristics of a transaction schedule will determine –whether it is “easy” to recover from transaction failures (see slide 10) –whether concurrent execution of transactions is “correct” (see slide 11)

9. 9 Characterizing Schedules based on Recoverability time T1T2T3T4T5T6T1T2T3T4T5T6 c1c1 c2c2 c3c3 c4c4 a6a6 What to do when transaction T 6 aborts? - Do we need to rollback transactions that have already committed (e.g., T 1..T 4 ) - Do we need to rollback other uncommitted transactions beside T 6 ? xx x x x x x x xx xx x xx xx x x x x x xx x x x x x x x x xx xx xx

10. 10 Characterizing Schedules based on Serializability Is the effect of executing transactions in the order shown in schedule D equivalent to executing transactions in the order shown in schedule A or B?

11. 1 Example l Consider the following transaction schedule r 1 (X) w 1 (X) r 2 (X) r 1 (Y) r 2 (Y) c 2 w 1 (Y) a 1 –If T 1 aborts, do we need to rollback the committed transaction T 2 ? –Answer: yes –Schedule is “non-recoverable”  This type of schedule makes the recovery process more cumbersome because we have to rollback transactions that have committed

12. 12 Recoverable Schedule l A schedule where no committed transactions need to be rolled back l A transaction T must not commit until all transactions T’ that have written an item that T reads have committed l Examples: –r 1 (X) w 1 (X) r 2 (X) r 1 (Y) w 2 (X) c 2 a 1  Nonrecoverable (T 2 must be rolled back when T 1 aborts) –r 1 (X) r 2 (X) w 1 (X) r 1 (Y) w 2 (X) c 2 w 1 (Y) a 1  Recoverable (T 2 does not have to be rolled back when T 1 aborts) –r 2 (X) w 2 (X) r 1 (X) r 1 (Y) w 1 (X) c 2 w 1 (Y) a 1  Recoverable (T 2 does not have to be rolled back when T 1 aborts)

13. 13 Is Recoverable Schedule Sufficient? l Example: r 1 (X) w 1 (X) r 2 (X) w 2 (X) a 1 –Recoverable because T 2 has not committed before T 1 –But the uncommitted transaction T 2 must still be aborted when T 1 aborts (cascading rollback) l Cascadeless schedule –A schedule with no cascading rollback, i.e., if a transaction T is aborted, we only need to rollback T and no other transactions –How do we ensure this?

14. 14 Cascadeless Schedules l Every transaction in the schedule reads only items that were written by committed transactions l Examples: –r 1 (X) w 1 (X) r 2 (X) r 3 (X) w 2 (X) c 2 a 1  Must rollback T 2 and T 3 (Not recoverable, not cascadeless) –r 1 (X) r 2 (X) w 1 (X) r 3 (X) w 2 (X) c 2 a 1  Must rollback T 3 only (Recoverable, not cascadeless) –r 1 (X) r 2 (X) r 3 (X) w 1 (X) c 2 a 1  No need to rollback T 2 nor T 3 (Recoverable, cascadeless) l Cascadeless schedules are recoverable and avoid cascading rollback

15. 15 Recovery using System Log l From previous lecture, if the database system crashes, we can recover to a consistent database state by examining the log l Example of entries in a log record (T: transaction ID) 1.[start_transaction,T 4 ] 2.[read_item,T 4.X] 3.[write_item,T 4.X,4,11] (before image = 4, after image = 11) 4.[abort,T 4 ] –During recovery, we may undo the change in T 4.X by using its “before image” (i.e., replace new value 11 with old value 4)

16. 16 Strict Schedules l But with concurrency, it is not always possible to restore the database to its original state after abort using the before image of data item l Example: r 2 (X) r 1 (X) w 1 (X) w 2 (X) a 1 –Is the transaction recoverable? –Is the transaction cascadeless? –If the original value for X is 5, T 1 modifies X to 10 and T 2 modifies it to 8. After we undo the changes of T 1, will X returned to a correct value?

17. 17 Strict Schedules l A schedule in which we can restore the database to a consistent state after abort using the before image of data item l A schedule in which a transaction can neither read nor write an item X until the last transaction that wrote X has committed or aborted l Example: r 2 (X) r 1 (X) w 1 (X) w 2 (X) a 1 –Schedule is cascadeless but not strict

18. 18 Characterizing Schedules based on Recoverability l Summary –Recoverable schedules: no need to rollback committed transactions –Cascadeless schedules: no cascading rollback (rollback only the aborted transaction) –Strict schedules: undo changes by aborted transaction by applying the before image of affected data items l Cascadeless schedules are recoverable l Strict schedules are cascadeless and recoverable l More stringent condition means easier to do recovery from failure but less concurrency

19. 19 Serial Schedules l A schedule S is serial if all operations in transactions are executed consecutively in the schedule –Otherwise, it is called nonserial schedule Serial: r 1 (X) w 1 (X) r 1 (Y) w 1 (Y) r 2 (X) w 2 (X)Nonserial: r 1 (X) w 1 (X) r 2 (X) w 2 (X) r 1 (Y) w 1 (Y)

20. 20 Serial Schedules l Every serial schedule is correct, i.e., leads to a consistent database state Schedule ASchedule Bread_item(X) X = X + 3 X = X – 2Y write_item(X) read_item(X) X = X – 2Y X = X + 3 write_item(X) write_item(X) –But executions of serial schedules are highly inefficient (because there is no concurrency)

21. 21 Serializable Schedules l A schedule S is serializable if its execution is equivalent to some serial schedule of the same transactions –Otherwise, S is non-serializable l We consider a special type of serializable schedule called conflict serializable schedule

22. 2 Conflict Serializable l A schedule S is said to be conflict serializable if it is conflict equivalent to some serial schedule of the same transactions –Two schedules are said to be conflict equivalent if the order of any two conflicting operations is the same in both schedules –Two operations in a transaction schedule are in conflict if  They belong to different transactions  They access the same data item  At least one of them is a write operation l If a schedule is conflict serializable, we can reorder the nonconflicting operations until we form an equivalent serial schedule

23. 23 Testing for Conflict Serializability l Construct a precedence graph (serialization graph) where –Nodes are the transactions –A directed edge is created from T i to T j if one of the operations in T i appears before a conflicting operation in T j  Create edge T i  T j if schedule contains w i (X) r j (X)  Create edge T i  T j if schedule contains r i (X) w j (X)  Create edge T i  T j if schedule contains w i (X) w j (X) l A schedule is conflict serializable if and only if the precedence graph has no cycles.

24. 24 Example

25. 25 Example This schedule is non-serializable because precedence graph has a cycle

26. 26 Example This schedule is conflict serializable because precedence graph has no cycle

27. 27 Equivalent Serial Schedule l If a schedule S is conflict serializable, we can create an equivalent serial schedule S’ as follows: –Whenever an edge exists in the precedence graph from T i to T j, T i must appear before T j in the equivalent serial schedule –Schedule A is the equivalent serial schedule for schedule D Precedence graph for schedule D

28. 28 Example Is it conflict serializable? What is the equivalent serial schedule?

29. 29 Example Is it conflict serializable? What is the equivalent serial schedule?

30. 30 Characterizing Schedules based on Serializability l Summary –Serial schedule is inefficient (no parallelism) –Serializable schedule gives benefits of concurrent executions without giving up correctness l Concurrency control subsystem of DBMS must use certain protocol to ensure serializability of all schedules in which the transactions participate –2-Phase locking protocol (Chapter 22) –May cause deadlocks –DBMS will automatically abort one of the transactions, releasing the locks for other transactions to continue

31. 31 MySQL Example Client 1: Client 2: Consider two concurrent transactions

32. 32 MySQL Example (Deadlock) Client 1: Client 2:

33. 3 MySQL Example (Deadlock) Client 1: Client 2: Client 1 will be kept busy waiting Deadlock detected by concurrency control module of DBMS; Transaction for client 2 is aborted, allowing transaction for client 1 to continue