2. UCDavis, ecs251 Spring 2007 04/17/2007Transactions1 Operating System Models ecs251 Spring 2007: Operating System Models #2: Transactions Dr. S. Felix Wu Computer Science Department University of California, Davis http://www.cs.ucdavis.edu/~wu/ sfelixwu@gmail.com

3. UCDavis, ecs251 Spring 2007 04/17/2007Transactions2 Transaction l A sequence/program of operations {read, write} on a set of “shared” variables

4. UCDavis, ecs251 Spring 2007 04/17/2007Transactions3 A Transaction System l A set of transactions being executed and sharing a set variables. l A lot of uncontrollability: –Failures of everything and any time –Distributed nature –Unpredictable scheduling –Dynamics about transactions themselves l Program changes, Self aborting, Birth,…

5. UCDavis, ecs251 Spring 2007 04/17/2007Transactions4 Applications of Transactions l Database/Information System l Distributed Mobile computing l Distributed File System l Fault Tolerant computing

6. UCDavis, ecs251 Spring 2007 04/17/2007Transactions5 Transaction Properties: ACID l Atomicity (all or nothing) l Consistency (consistent state transition) l Isolation (intermediate results) l Durability (persistent)

7. UCDavis, ecs251 Spring 2007 04/17/2007Transactions6 Transaction Properties: ACID l Atomicity (all or nothing) l Consistency (consistent state transition) l Isolation (intermediate results) l Durability (persistent) l Let’s not worry about the details for now…

8. UCDavis, ecs251 Spring 2007 04/17/2007Transactions7 (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 R t (O): Transaction t READ object O W t (O): Transaction t WRITE object O

9. UCDavis, ecs251 Spring 2007 04/17/2007Transactions8 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) Transaction Execution History time

10. UCDavis, ecs251 Spring 2007 04/17/2007Transactions9 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) Transaction Execution History time T b >> T c >> T a or “bca”

11. UCDavis, ecs251 Spring 2007 04/17/2007Transactions10 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) Transaction Execution History time

12. UCDavis, ecs251 Spring 2007 04/17/2007Transactions11 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) Does this schedule look OK? time

13. UCDavis, ecs251 Spring 2007 04/17/2007Transactions12 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) Y only: abc, acb, bac, bca, cab, cba ?? time abc Y Y Y

14. UCDavis, ecs251 Spring 2007 04/17/2007Transactions13 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) X only: abc, acb, bac, bca, cab, cba ?? time abc

15. UCDavis, ecs251 Spring 2007 04/17/2007Transactions14 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) Z only: abc, acb, bac, bca, cab, cba ?? time abc

16. UCDavis, ecs251 Spring 2007 04/17/2007Transactions15 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) Transaction Execution History time abc Y Y Y,Z X

17. UCDavis, ecs251 Spring 2007 04/17/2007Transactions16 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.

18. UCDavis, ecs251 Spring 2007 04/17/2007Transactions17 The Transaction Model PrimitiveDescription BEGIN_TRANSACTIONMake the start of a transaction END_TRANSACTIONTerminate the transaction and try to commit ABORT_TRANSACTIONKill the transaction and restore the old values READRead data from a file, a table, or otherwise WRITEWrite data to a file, a table, or otherwise

19. UCDavis, ecs251 Spring 2007 04/17/2007Transactions18 Transaction Execution Histories SuccessfulAborted by clientAborted by server BeginTransaction operation server aborts transaction operation operation ERROR reported to client EndTransactionAbortTransaction

20. UCDavis, ecs251 Spring 2007 04/17/2007Transactions19 Serial equivalence l 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 l 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 l 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).

21. UCDavis, ecs251 Spring 2007 04/17/2007Transactions20Serializability BEGIN_TRANSACTION read X; read Y; write Y END_TRANSACTION (a) BEGIN_TRANSACTION read X; read Z; write Z; END_TRANSACTION (b) BEGIN_TRANSACTION read Y; read Z; read X; END_TRANSACTION (c) Illegalr[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]cSchedule 3 Legalr[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]cSchedule 2 Legalr[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]cSchedule 1 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

22. UCDavis, ecs251 Spring 2007 04/17/2007Transactions21 operation conflict rules l Conflicting operations l 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) Operations of different transactions ConflictReason read NoBecause the effect of a pair ofread operations does not depend on the order in which they are executed readwriteYesBecause the effect of aread and awrite operation depends on the order of their execution write YesBecause the effect of a pair ofwrite operations depends on the order of their execution

23. UCDavis, ecs251 Spring 2007 04/17/2007Transactions22Serializability l 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.

24. UCDavis, ecs251 Spring 2007 04/17/2007Transactions23 Concurrency Control l We might not be able to control the scheduler. l 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

25. UCDavis, ecs251 Spring 2007 04/17/2007Transactions24 Lock-based CC l Two extra operations: –lock and unlock l The problem is where and when to put these new operations??

26. UCDavis, ecs251 Spring 2007 04/17/2007Transactions25 (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)

27. UCDavis, ecs251 Spring 2007 04/17/2007Transactions26 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)

28. UCDavis, ecs251 Spring 2007 04/17/2007Transactions27 (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)

29. UCDavis, ecs251 Spring 2007 04/17/2007Transactions28 (a) lock(Y) lock(X) 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)

30. UCDavis, ecs251 Spring 2007 04/17/2007Transactions29 (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)

31. UCDavis, ecs251 Spring 2007 04/17/2007Transactions30 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) abc

32. UCDavis, ecs251 Spring 2007 04/17/2007Transactions31 Two-Phase Locking l Two-phase locking.

33. UCDavis, ecs251 Spring 2007 04/17/2007Transactions32 Strict Two-Phase Locking l Strict two-phase locking. Commit or Abort 1.prevent dirty read and immature write 2.we don’t really know where the lock point is!!

34. UCDavis, ecs251 Spring 2007 04/17/2007Transactions33 Lock compatibility (read, write and commit locks) For one objectLock to be set readwritecommit Lock already setnoneOK readOK wait writeOKwait commitwait

35. UCDavis, ecs251 Spring 2007 04/17/2007Transactions34 Time-Stamp Ordering l “Serial Equivalence”  One particular order, e.g., “abc”. l 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”. l Problem: how to assign the order among transactions?

36. UCDavis, ecs251 Spring 2007 04/17/2007Transactions35 Time Stamp Ordering l TS_start (T): each T will get a unique TS. –It should remain the same until abort/commit. –First Come First Serve. l For each object X: –TS_read (X): l The largest TS_start among T’s who had read X –TS_write(X): l The largest TS_start among T’s who had written X –The values only monotonically increase. l 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. l Read: TS_start(T) >= TS_write(X) –T’s future has not been written.

37. UCDavis, ecs251 Spring 2007 04/17/2007Transactions36 Operation conflicts for timestamp ordering Rule TcTc TiTi 1.writereadTcTc must notwrite an object that has beenread by anyTiTi where this requires thatTcTc ≥ the maximum read timestamp of the object. 2.write TcTc must notwrite an object that has beenwritten by anyTiTi where TiTi >TcTc this requires thatTcTc > write timestamp of the committedobject. 3.readwriteTcTc must notread an object that has beenwritten by anyTiTi where this requires thatTcTc > write timestamp of the committed object. TiTi >TcTc TiTi >TcTc

38. UCDavis, ecs251 Spring 2007 04/17/2007Transactions37 (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)

39. UCDavis, ecs251 Spring 2007 04/17/2007Transactions38 TS start a = 1 R(X) = 1 W(X) = 1 TS start b = 2 R(Z) = 2 TS start c = 3 RW X Y Z 1 1 2 00 0 RW X Y Z 0 0 0 00 0

40. UCDavis, ecs251 Spring 2007 04/17/2007Transactions39 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 3 (v1<3 == R(Y)) TS start b = 2 R(Z) = 2 R(Y) = 3 (v2<3) TS start c = 3 R(Y)= 3 R(Z)= 3 RW X Y Z 1 1 3 30 0 (1 > 0 == W(Y)) RW X Y Z 1 1 2 00 0 (2 > 0 == W(Y))

41. UCDavis, ecs251 Spring 2007 04/17/2007Transactions40 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 3 (1<3) W(Y) abort (1 < (R(Y) == 3)) TS start b = 2 R(Z) = 2 R(Y) = 3 (2<3) W(Y) abort (2 < (R(Y) == 3)) R(X) W(X) TS start c = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 RW X Y Z 1 1 3 33 3

42. UCDavis, ecs251 Spring 2007 04/17/2007Transactions41 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TS start b = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TS start c = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3 Which one(s) will commit?

43. UCDavis, ecs251 Spring 2007 04/17/2007Transactions42 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TS start b = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TS start c = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3

44. UCDavis, ecs251 Spring 2007 04/17/2007Transactions43 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TS start b = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TS start c = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3

45. UCDavis, ecs251 Spring 2007 04/17/2007Transactions44 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TS start b = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TS start c = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3

46. UCDavis, ecs251 Spring 2007 04/17/2007Transactions45 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TS start b = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TS start c = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3

47. UCDavis, ecs251 Spring 2007 04/17/2007Transactions46 TS start a = 1 R(X) = 1 W(X) = 1 R(Y) = 2 W(Y) = 3 TS start b = 2 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(X) = 2 W(X) = 2 TS start c = 3 R(Y)= 3 R(Z)= 3 W(Y)= 3 W(Z)= 3

48. UCDavis, ecs251 Spring 2007 04/17/2007Transactions47 T1: begin transaction query cs.ucdavis.edu query x123.google.com query mail.yahoo.com end transaction T2: begin transaction query cs.ucdavis.edu update cs.ucdavis.edu query x123.google.com update x123.google.com end transaction T3: begin transaction query mail.yahoo.com update mail.yahoo.com query x123.google.com update x123.google.com end transaction DNS Transactions Consistent Name-IPAddr Mappings e.g., web site upgrading

49. UCDavis, ecs251 Spring 2007 04/17/2007Transactions48 HW#2 Programming Part l Transaction Execution History –Operation {R, W} –Object Identifier (an integer) –Transaction Identifier (an integer) l Answer: –Serializable or not –Can this input execution history be produced by 2PL, TSO, or OCC? l Due Date: May 31, 2007 (1~2 students per team) l I will provide the test cases. l We will do “interactive grading”!

50. UCDavis, ecs251 Spring 2007 04/17/2007Transactions49 HW#2 Writing Part l I will post a few questions (like HW#1) regarding distributed file systems (NFS, AFS, GFS, and Coda). l During the interactive grading session, I will ask questions as well.

51. UCDavis, ecs251 Spring 2007 04/17/2007Transactions50 OCC: Optimistic Concurrency Control Execute the Transaction Validation logging Commit or abort??

52. UCDavis, ecs251 Spring 2007 04/17/2007Transactions51 Three Phases in OCC Working phase –the transaction uses a tentative version of the objects it accesses (dirty reads can’t occur as we read from a committed version or a copy of it) –the coordinator records the readset and writeset of each transaction Validation phase –at closeTransaction the coordinator validates the transaction (looks for conflicts) –if the validation is successful the transaction can commit. –if it fails, either the current transaction, or one it conflicts with is aborted Update phase –If validated, the changes in its tentative versions are made permanent. –read-only transactions can commit immediately after passing validation.

53. UCDavis, ecs251 Spring 2007 04/17/2007Transactions52 OCC Data Structure l Object l Transaction –ReadSet: objects read by T –WriteSet: objects written by T –Shadow Copies: copies of objects written by T but not yet committed (temporary copies) Real R W R W

54. UCDavis, ecs251 Spring 2007 04/17/2007Transactions53 OCC Operations l T.read (Object Obj) –add Obj to T.ReadSet –if Obj in T.WriteSet, return T.Copies(Obj) –otherwise return Real(Obj); l T.write (Object Obj, Value V) –add Obj to T.WriteSet –if Obj in T.WriteSet, update T.Copies(Obj) –otherwise, create T.Copies(Obj), and update it.

55. UCDavis, ecs251 Spring 2007 04/17/2007Transactions54 How to Validate?? Execute the Transaction Validation logging

56. UCDavis, ecs251 Spring 2007 04/17/2007Transactions55 How to Validate?? l Assign the Transaction number –similar to the TSO, but until the beginning of the validation phase.

57. UCDavis, ecs251 Spring 2007 04/17/2007Transactions56 How to Validate?? l Assign the Transaction number –similar to the TSO, but until the beginning of the validation phase. l According to the “Order”, try to detect conflicts for a particular transaction, T current –Have T current read anything that have been updated since then? –Validate against all the transactions committed earlier, but finished their update phase after the starting time of the transaction. l “Backward Validation”  “Forward” l “Serial Validation”  “Parallel”

58. UCDavis, ecs251 Spring 2007 04/17/2007Transactions57 Three Phases in OCC WorkingValidationUpdate Starting Time of the Transaction Commit

59. UCDavis, ecs251 Spring 2007 04/17/2007Transactions58 OCC transactions Earlier committed transactions WorkingValidationUpdate T 1 T current Transaction being validated T 2 T 3 Later active transactions active 1 2

60. UCDavis, ecs251 Spring 2007 04/17/2007Transactions59 Which ones should we consider? Earlier committed transactions WorkingValidationUpdate T 1 T current Transaction being validated T 2 T 3 Later active transactions active 1 2

61. UCDavis, ecs251 Spring 2007 04/17/2007Transactions60 OCC Conflict Detection l Transactions entering the commit queue. l Conflicts: –if T reads something that has been updated by “earlier” committed transactions. T R-set W-set T R-set W-set T R-set W-set T R-set W-set T R-set W-set committedcurrentcommitted

62. UCDavis, ecs251 Spring 2007 04/17/2007Transactions61 Why not Write-Write conflicts? l WW conflicts: –In OCC, all the writes are performed in one shot (atomically)!!

63. UCDavis, ecs251 Spring 2007 04/17/2007Transactions62 (a) W(X) W(Z) (b) W(Y) W(X) (c) W(Y) W(Z)

64. UCDavis, ecs251 Spring 2007 04/17/2007Transactions63 (a) W(X) W(Z) (b) W(Y) W(X) (c) W(Y) W(Z)

65. UCDavis, ecs251 Spring 2007 04/17/2007Transactions64 (a) validation W(X) W(Z) (b) validation W(Y) W(X) (c) validation W(Y) W(Z)

66. UCDavis, ecs251 Spring 2007 04/17/2007Transactions65 Validation of Transactions Backward validation of transaction T v boolean valid = true; for (int T i = startTn+1; T i <= finishTn; T i ++){ if (read set of T v intersects write set of T i ) valid = false; } Forward validation of transaction T v boolean valid = true; for (int T id = active1; T id <= activeN; T id ++){ if (write set of T v intersects read set of T id ) valid = false; }

67. UCDavis, ecs251 Spring 2007 04/17/2007Transactions66 An Optimization T 102 R-set W-set T 101 R-set W-set T 97 R-set W-set T 92 R-set W-set T 103 R-set W-set committedcurrentcommitted conflict Problem: ReadSet (T 103 ) intersects with WriteSet (T 101 ) Assume that WriteSet (T 103 ) does NOT intersect with ReadSet (T 101 ) Do we have any hope NOT to abort T 103 ?

68. UCDavis, ecs251 Spring 2007 04/17/2007Transactions67 Forward Validation l Try to detect conflicts for other transactions against T current –Have T current updated anything that have been read EVER? –Validate against all the transactions not yet committed. l Every Object should have a “ReadSet” (which transactions have read this object).

69. UCDavis, ecs251 Spring 2007 04/17/2007Transactions68 OCC - Serial Validation committedcommittingworking/in progress transaction number being assigned Latest Committed transaction

70. UCDavis, ecs251 Spring 2007 04/17/2007Transactions69 Parallel Validation l Can I validate multiple transactions at the same time?

71. UCDavis, ecs251 Spring 2007 04/17/2007Transactions70 How to Validate in Parallel?? l Assign the Transaction number –similar to the TSO, but when?? l According to the “Order”, try to detect conflicts for a particular transaction, T current –Have T current read anything that have been updated since then? How about other “committing” transactions? –Validate against all the transactions committed or committing earlier, but finished their update phase after the starting time of the transaction.

72. UCDavis, ecs251 Spring 2007 04/17/2007Transactions71 OCC - Parallel Validation committedcommittingworking/in progress transaction number being assigned Latest Committed transaction ….. difference: against themselves as well abc acb bac bca cab cba committing ab ba

73. UCDavis, ecs251 Spring 2007 04/17/2007Transactions72 OCC - PV committedcommittingworking/in progress transaction number being assigned Latest Committed transaction …..

74. UCDavis, ecs251 Spring 2007 04/17/2007Transactions73OCC l the scheme is called optimistic because the likelihood of two transactions conflicting is low l a transaction proceeds without restriction until the closeTransaction (no waiting, therefore no deadlock) l it is then checked to see whether it has come into conflict with other transactions l when a conflict arises, a transaction is aborted l each transaction has three phases

75. UCDavis, ecs251 Spring 2007 04/17/2007Transactions74 Validation of transactions l We use the read-write conflict rules –to ensure a particular transaction is serially equivalent with respect to all other overlapping transactions l each transaction is given a transaction number when it starts validation (the number is kept if it commits) l the rules ensure serializability of transaction T v (transaction being validated) with respect to transaction T i TvTv TiTi Rule writeread1.TiTi must not read objects written byTvTv readwrite2.TvTv must not read objects written byTiTi write 3.TiTi must not write objects written byTvTv and TvTv mustnot write objects written byTiTi forward backward

76. UCDavis, ecs251 Spring 2007 04/17/2007Transactions75 OCC: Optimistic Concurrency Control Execute the Transaction Validation logging Concurrency?? Security?? Semantic Conflict detection Intrusion detection Abort  conflict resolution

77. UCDavis, ecs251 Spring 2007 04/17/2007Transactions76 AFS l State-ful clients and servers. l Caching the files to clients. –File close ==> check-in the changes. l How to maintain consistency? –Using “Callback” in v2/3 open read applications invalidate and re-cache

78. UCDavis, ecs251 Spring 2007 04/17/2007Transactions77 Other Applications?? l In what situations, the optimistic approach might be better than the traditional locking approach?

79. UCDavis, ecs251 Spring 2007 04/17/2007Transactions78 Special Cases l Long-life transactions –??? l Read-only transactions –Maybe a very common case –Die versus Kill

80. UCDavis, ecs251 Spring 2007 04/17/2007Transactions79 Multi-Versions l Data update history for every object. l Every version has a logical timestamp

81. UCDavis, ecs251 Spring 2007 04/17/2007Transactions80 Multi-Versions X Y time

82. UCDavis, ecs251 Spring 2007 04/17/2007Transactions81 Multi-Versions X Y Real Time Initial Value

83. UCDavis, ecs251 Spring 2007 04/17/2007Transactions82 Multi-Versions X Y Real Time Initial Value

84. UCDavis, ecs251 Spring 2007 04/17/2007Transactions83 MV -- Global VTS X Y Virtual Time Initial Value

85. UCDavis, ecs251 Spring 2007 04/17/2007Transactions84 Real-Only Transaction l How to make sure that ROT will never be aborted?

86. UCDavis, ecs251 Spring 2007 04/17/2007Transactions85 MV -- Global VTS X Y Virtual Time Initial Value

87. UCDavis, ecs251 Spring 2007 04/17/2007Transactions86 C MV -- Global VTS X Y Virtual Time Initial Value

88. UCDavis, ecs251 Spring 2007 04/17/2007Transactions87 Deciding the right “GTS”

89. UCDavis, ecs251 Spring 2007 04/17/2007Transactions88 Deciding the right “GTS” l Get the latest committed version # from “every object” (we have to know the Read Set in advance or maybe we will be aborted at most ONCE) l Choose the “smallest” # as the GTS for this read-only transaction?

90. UCDavis, ecs251 Spring 2007 04/17/2007Transactions89 Inactive Object

91. UCDavis, ecs251 Spring 2007 04/17/2007Transactions90 Distributed OCC l Distributed Files systems

92. UCDavis, ecs251 Spring 2007 04/17/2007Transactions91 local OCC on 1 server: Optimistic Concurrency Control Execute the Transaction Validation logging Abort  conflict resolution T R-set W-set T R-set W-set T R-set W-set T R-set W-set T R-set W-set committedcurrentcommitted 2PC

93. UCDavis, ecs251 Spring 2007 04/17/2007Transactions92DOCC [tID 22] R-set W-set [tID 05] R-set W-set [tID 17] R-set W-set [tID 67] R-set W-set [tID 34] R-set W-set committedcurrentcommitted Transaction-ID: tID Validation-Order-ID:vID Server X: Server Y: What is the issue here? [tID 05] R-set W-set [tID 34] R-set W-set [tID 17] R-set W-set [tID 67] R-set W-set [tID 22] R-set W-set committedcurrentcommitted [vID 03][vID 05][vID 06] [vID 11][vID 12][vID 16]

94. UCDavis, ecs251 Spring 2007 04/17/2007Transactions93DOCC [tID 22] R-set W-set [tID 05] R-set W-set [tID 17] R-set W-set [tID 67] R-set W-set [tID 34] R-set W-set committedcurrentcommitted Transaction-ID: tID Validation-Order-ID:vID Server X: Server Y: Local serializable, but not global serializable!! [tID 05] R-set W-set [tID 34] R-set W-set [tID 17] R-set W-set [tID 67] R-set W-set [tID 22] R-set W-set committedcurrentcommitted [vID 03][vID 05][vID 06] [vID 11][vID 12][vID 16]

95. UCDavis, ecs251 Spring 2007 04/17/2007Transactions94 Distribited OCC l How to extend OCC to a distributed system? –distributed 3 phases: working, validation, and writing –how to coordinate?

96. UCDavis, ecs251 Spring 2007 04/17/2007Transactions95 Distributed OCC Coordinator Server ….. How to assign “consistent” transaction # to the same global transaction? OCC What is the problem? Coordinator

97. UCDavis, ecs251 Spring 2007 04/17/2007Transactions96 Maximum Validation ID Coordinator Server ….. Coordinator mvID:the largest validation-ID being assigned on a local server!! [mvID]

98. UCDavis, ecs251 Spring 2007 04/17/2007Transactions97 Getting the vID Right!! l C  S –What is the current value of [mvID]? l S  C –Answer l C  S –C chooses a value (max{mvID i } + delta) l S  C –success or not l C  S –validation start if all succeed.

99. UCDavis, ecs251 Spring 2007 04/17/2007Transactions98 Readings l OCC (Kung-Robinson) l DMV-OCC