ecs251 Spring 2012: Operating System Models #3: Transactions

1. ecs251 Spring 2012:Operating System Models#3: Transactions Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com ecs251, winter 2013

2. Consistency Model • Metadata is atomic. • Relatively simple, since just a single master. • Consider a set of data modifications, and a set of reads all executed by different clients. • Furthermore, assume that the reads are executed a “sufficient” time after the writes. • Consistent if all clients see the same thing. • Defined if all clients see the modification in its entirety (atomic). ecs251, winter 2013

3. Transaction • A sequence/program of operations {read, write} on a set of “shared” variables ecs251, winter 2013

4. A Transaction System • A set of transactions being executed and sharing a set variables. • A lot of uncontrollability: • Failures of everything and any time • Distributed nature • Unpredictable scheduling • Dynamics about transactions themselves • Program changes, Self aborting, Birth,… ecs251, winter 2013

5. Applications of Transactions • Database/Information System • Distributed Mobile computing • Distributed File System • Fault Tolerant computing ecs251, winter 2013

6. Transaction Properties: ACID • Atomicity (all or nothing) • Consistency (consistent state transition) • Isolation (intermediate results) • Durability (persistent) ecs251, winter 2013

7. Transaction Properties: ACID • Atomicity (all or nothing) • Consistency (consistent state transition) • Isolation (intermediate results) • Durability (persistent) • Let’s not worry about the details for now… ecs251, winter 2013

8. (a) R(X) W(X) R(Y) W(Y) (b) R(Z) R(Y) W(Y) R(X) W(X) (c) R(Y) R(Z) W(Y) W(Z) Three Transactions: a,b, and c Assuming we have only one copy of X, Y, & Z Rt(O): Transaction t READ object O Wt(O): Transaction t WRITE object O ecs251, winter 2013

9. Transaction Execution History time R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

10. Transaction Execution History time R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

11. Transaction Execution History time R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) Tb >> Tc >> Ta or “bca” ecs251, winter 2013

12. Transaction Execution History time R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

13. Does this schedule look OK? time R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

14. Y only: abc, acb, bac, bca, cab, cba ?? time Y a b c Y Y R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

15. X only: abc, acb, bac, bca, cab, cba ?? time a b c R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

16. Z only: abc, acb, bac, bca, cab, cba ?? time a b c R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

17. Transaction Execution History time X Y,Z a b c Y Y R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

18. Operations in Coordinator interface • BeginTransaction() -> trans; • starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction. • EndTransaction(trans) -> (commit, abort); • ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted. • AbortTransaction(trans); • aborts the transaction. ecs251, winter 2013

19. The Transaction Model ecs251, winter 2013

20. Transaction Execution Histories Successful Aborted by client Aborted by server BeginTransaction BeginTransaction BeginTransaction operation operation operation operation operation operation server aborts transaction operation operation operation ERROR reported to client EndTransaction AbortTransaction ecs251, winter 2013

21. Serial equivalence • if each one of a set of transactions has the correct effect when done on its own alone, then if they are done one at a time in some order the effect will be correct • a serially equivalent interleaving is one in which the combined effect is the same as if the transactions had been done one at a time in some order • abc, acb, bac, bca, cab, or cba • the same effect means • the read operations return the same values (to one order) • the instance variables of the objects have the same values at the end (of each transaction). • ecs251, winter 2013

22. Serializability Schedule 1 r[X]a, r[Y]a, w[Y]a, r[X]b, r[Z]b, w[Z]b, r[Y]c, r[Z]c, r[X]c Legal Schedule 2 r[X]a, r[X]b, r[Z]b, r[Y]a, w[Z]b, w[Y]a, r[Y]c, r[Z]c, r[X]c Legal Schedule 3 r[X]a, r[X]b, r[Z]b, r[Y]a, r[Y]c, w[Z]b, w[Y]a, r[Z]c, r[X]c Illegal r[X]a, r[X]b, r[Z]b, r[Y]a, r[Y]c, r[Z]c, w[Z]b, r[X]c, w[Y]a r[X]a, r[X]b, r[Z]b, r[Y]c, r[Y]a, w[Z]b, r[Z]c, r[X]c, w[Y]a ecs251, winter 2013

23. operation conflict rules Operations of different Conflict Reason transactions • Conflicting operations • a pair of operations conflicts if their combined effect depends on the order in which they were performed • e.g. read and write (whose effects are the result returned by read and the value set by write) read read No Because the effect of a pair of read operations does not depend on the order in which they are executed read write Yes Because the effect of a read and a write operation depends on the order of their execution write write Yes Because the effect of a pair of write operations depends on the order of their execution ecs251, winter 2013

24. Serializability • Given a transaction execution history, check all the operation conflicts. • Check whether you can find a serializable schedule to satisfy all the conflicts, or • Check if the conflict dependency graph is acyclic or not. ecs251, winter 2013

25. Concurrency Control • We might not be able to control the scheduler. • Let’s use some mechanisms (such as mutex, cond, or other) to stop certain threads to avoid “non-serializable” execution history. • locking • time-stamping • optimistic approach ecs251, winter 2013

26. Lock-based CC • Two extra operations: • lock and unlock • The problem is where and when to put these new operations?? ecs251, winter 2013

27. (a) lock(X) R(X) W(X) unlock(X) lock(Y) R(Y) W(Y) unlock(Y) (b) lock(Z) R(Z) unlock(Z) lock(Y) R(Y) W(Y) unlock(Y) lock(X) R(X) W(X) unlock(X) (c) lock(Y) R(Y) lock(Z) R(Z) W(Y) unlock(Y) W(Z) unlock(Z) ecs251, winter 2013

28. lock(X) R(X) W(X) unlock(X) lock(Y) R(Y) W(Y) unlock(Y) lock(Z) R(Z) unlock(Z) lock(Y) R(Y) W(Y) unlock(Y) lock(X) R(X) W(X) unlock(X) lock(Y) R(Y) lock(Z) R(Z) W(Y) unlock(Y) W(Z) unlock(Z) ecs251, winter 2013

29. Transaction Execution History time X Y,Z a b c Y Y R(X) W(X) R(Y) W(Y) R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

30. (a) lock(X) lock(Y) lock(Z) R(X) W(X) R(Y) W(Y) unlock(Z) unlock(Y) unlock(X) (b) lock(X) lock(Y) lock(Z) R(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) unlock(X) (c) lock(X) lock(Y) lock(Z) R(Y) R(Z) W(Y) W(Z) unlock(Z) unlock(Y) unlock(X) ecs251, winter 2013

31. (a) Lock(X) Lock(Y) R(X) W(X) R(Y) W(Y) unlock(X) unlock(Y) (b) lock(X) lock(Y) lock(Z) R(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) unlock(X) (c) lock(Y) lock(Z) R(Y) R(Z) W(Y) W(Z) unlock(Z) unlock(Y) ecs251, winter 2013

32. (a) lock(X) R(X) W(X) Lock(Y) Unlock(x) R(Y) W(Y) unlock(Y) (b) lock(X) lock(Y) lock(Z) R(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) unlock(X) (c) lock(Y) R(Y) Lock(z) R(Z) W(Y) Unlock(Y) W(Z) unlock(Z) ecs251, winter 2013

33. (a) lock(X) R(X) W(X) Lock(Y) Unlock(x) R(Y) W(Y) unlock(Y) (b) lock(X) lock(Y) lock(Z) R(Z) unlock(Z) R(Y) W(Y) unlock(Y) R(X) W(X) unlock(X) (c) lock(Y) R(Y) Lock(z) R(Z) W(Y) Unlock(Y) W(Z) unlock(Z) ecs251, winter 2013

34. lock(X) lock(Y) R(X) W(X) R(Y) W(Y) unlock(Y) unlock(X) lock(X) lock(Y) lock(Z) R(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) unlock(X) lock(Y) lock(Z) R(Y) R(Z) W(Y) W(Z) unlock(Z) unlock(Y) a b c ecs251, winter 2013

35. Two-Phase Locking • Two-phase locking. ecs251, winter 2013

36. Strict Two-Phase Locking • Strict two-phase locking. Commit or Abort • prevent dirty read and immature write • we don’t really know where the lock point is!! ecs251, winter 2013

37. For one object Lock to be set read write commit Lock already set none OK OK OK read OK OK wait write OK wait commit wait wait Lock compatibility (read, write and commit locks) ecs251, winter 2013

38. Time-Stamp Ordering • “Serial Equivalence” One particular order, e.g., “abc”. • TSO sets the “order” from the beginning and enforce that the “execution history” must strictly follow that order. • If we decide “abc”, then we will not allow “bac”. • Problem: how to assign the order among transactions? ecs251, winter 2013

39. Time Stamp Ordering • TS_start (T): each T will get a unique TS. • It should remain the same until abort/commit. • First Come First Serve. • For each object X: • TS_read (X): • The largest TS_start among T’s who had read X • TS_write(X): • The largest TS_start among T’s who had written X • The values only monotonically increase. • Write: TS_start(T) >= TS_read(X) • T’s future has not been read. • TS_start(T) < TS_write(X)  skip the write but continue. • Read: TS_start(T) >= TS_write(X) • T’s future has not been written. ecs251, winter 2013

40. Rule Tc Ti 1. write read Tc must not write an object that has been read by any Ti where Ti > Tc this requires that Tc ≥ the maximum read timestamp of the object. Ti > Tc 2. write write Tc must not write an object that has been written by any Ti where this requires that Tc > write timestamp of the committed object. Ti > Tc 3. read write Tc must not read an object that has been written by any Ti where this requires that Tc > write timestamp of the committed object. Operation conflicts for timestamp ordering ecs251, winter 2013

41. (a) R(X) W(X) R(Y) W(Y) (b) R(Z) R(Y) W(Y) R(X) W(X) (c) R(Y) R(Z) W(Y) W(Z) ecs251, winter 2013

42. R R W W X X Y Y Z Z TSstarta = 1 R(X) = 1 W(X) = 1 TSstartb = 2 R(Z) = 2 TSstartc = 3 1 1 0 0 0 0 0 0 2 0 0 0 ecs251, winter 2013

43. R R W W X X Y Y Z Z TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 3 (v1<3 == R(Y)) TSstartb = 2 R(Z) = 2 R(Y) = 3(v2<3) TSstartc = 3 R(Y)= 3 R(Z)= 3 (1 > 0 == W(Y)) (2 > 0 == W(Y)) 1 1 1 1 0 0 3 0 2 0 3 0 ecs251, winter 2013

44. R W X Y Z TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 3 (1<3) W(Y) abort (1 < (R(Y) == 3)) TSstartb = 2 R(Z) = 2 R(Y) = 3 (2<3) W(Y) abort (2 < (R(Y) == 3)) R(X) W(X) TSstartc = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 1 1 3 3 3 3 ecs251, winter 2013

45. TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TSstartb = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TSstartc = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 Which one(s) will commit? ecs251, winter 2013

46. TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TSstartb = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TSstartc = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 ecs251, winter 2013

47. TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TSstartb = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TSstartc = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 ecs251, winter 2013

48. TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TSstartb = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TSstartc = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 ecs251, winter 2013

49. TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TSstartb = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TSstartc = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 ecs251, winter 2013

50. TSstarta = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TSstartb = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TSstartc = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 ecs251, winter 2013