UCDavis ecs 251 Spring 2012 ecs 251 Spring

UCDavis, ecs 251 Spring 2012 ecs 251 Spring 2014: 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 5/6/14 ecs 251, spring 2014 1

UCDavis, ecs 251 Spring 2014 Consistency Model l Metadata is atomic. – Relatively simple, since just a single master. l Consider a set of data modifications, and a set of reads all executed by different clients. l 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). 5/6/14 ecs 251, spring 2014 2

UCDavis, ecs 251 Spring 2014 Transaction l A sequence/program of operations {read, write} on a set of “shared” variables 5/6/14 ecs 251, spring 2014 3

UCDavis, ecs 251 Spring 2014 A Transaction System A set of transactions being executed and sharing a set variables. l A lot of uncontrollability: l – Failures of everything and any time – Distributed nature – Unpredictable scheduling – Dynamics about transactions themselves l 5/6/14 Program changes, Self aborting, Birth, … ecs 251, spring 2014 4

UCDavis, ecs 251 Spring 2014 Applications of Transactions Database/Information System l Distributed Mobile computing l Distributed File System l Fault Tolerant computing l 5/6/14 ecs 251, spring 2014 5

UCDavis, ecs 251 Spring 2014 Transaction Properties: ACID Atomicity (all or nothing) l Consistency (consistent state transition) l Isolation (intermediate results) l Durability (persistent) l 5/6/14 ecs 251, spring 2014 6

UCDavis, ecs 251 Spring 2014 Transaction Properties: ACID Atomicity (all or nothing) l Consistency (consistent state transition) l Isolation (intermediate results) l Durability (persistent) l l 5/6/14 Let’s not worry about the details for now… ecs 251, spring 2014 7

UCDavis, ecs 251 Spring 2014 (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 5/6/14 ecs 251, spring 2014 8

UCDavis, ecs 251 Spring 2014 Transaction Execution History time R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) R(X) W(X) R(Y) W(Y) 5/6/14 ecs 251, spring 2014 9

UCDavis, ecs 251 Spring 2014 time Transaction Execution History R(X) W(X) R(Y) W(Y) R(Z) W(Y) W(Z) R(Y) W(Y) R(X) W(X) 5/6/14 ecs 251, spring 2014 10

UCDavis, ecs 251 Spring 2014 Transaction Execution History time R(Z) R(Y) W(Y) R(X) W(X) R(Y) R(Z) W(Y) W(Z) R(X) W(X) R(Y) W(Y) 5/6/14 Tb >> Tc�>> Ta or “bca” ecs 251, spring 2014 11

UCDavis, ecs 251 Spring 2014 Transaction Execution History time R(Z) R(Y) W(Y) R(Z) R(X) W(Y) W(Z) R(X) R(Y) W(X) 5/6/14 ecs 251, spring 2014 12

UCDavis, ecs 251 Spring 2014 Does this schedule look OK? time R(Z) R(Y) W(Y) R(Z) R(X) W(Y) W(Z) R(X) R(Y) W(X) 5/6/14 ecs 251, spring 2014 13

UCDavis, ecs 251 Spring 2014 Y only: abc, acb, bac, bca, cab, cba ? ? a Y R(Z) R(Y) W(Y) time b Y Y c R(Y) R(Z) R(X) W(Y) W(Z) R(X) R(Y) W(X) 5/6/14 ecs 251, spring 2014 14

UCDavis, ecs 251 Spring 2014 X only: abc, acb, bac, bca, cab, cba ? ? a R(Z) R(Y) W(Y) time b c R(Y) R(Z) R(X) W(Y) W(Z) R(X) R(Y) W(X) 5/6/14 ecs 251, spring 2014 15

UCDavis, ecs 251 Spring 2014 Z only: abc, acb, bac, bca, cab, cba ? ? a R(Z) R(Y) W(Y) time b c R(Y) R(Z) R(X) W(Y) W(Z) R(X) R(Y) W(X) 5/6/14 ecs 251, spring 2014 16

UCDavis, ecs 251 Spring 2014 Transaction Execution History time R(Z) R(Y) W(Y) a X Y b Y, Z Y R(Y) R(Z) R(X) W(Y) W(Z) R(X) R(Y) W(X) 5/6/14 ecs 251, spring 2014 17 c

UCDavis, ecs 251 Spring 2014 Operations in Coordinator interface Begin. Transaction() -> trans; starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction. End. Transaction(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. Abort. Transaction(trans); aborts the transaction. 5/6/14 ecs 251, spring 2014 18

UCDavis, ecs 251 Spring 2014 The Transaction Model Primitive Description BEGIN_TRANSACTION Make the start of a transaction END_TRANSACTION Terminate the transaction and try to commit ABORT_TRANSACTION Kill the transaction and restore the old values READ Read data from a file, a table, or otherwise WRITE Write data to a file, a table, or otherwise 5/6/14 ecs 251, spring 2014 19

UCDavis, ecs 251 Spring 2014 Transaction Execution Histories Successful Begin. Transaction operation Aborted by client Begin. Transaction operation server aborts transaction operation End. Transaction Abort. Transaction 5/6/14 ecs 251, spring 2014 Aborted by server Begin. Transaction operation ERROR reported to client 20

UCDavis, ecs 251 Spring 2014 l l 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 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 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). 5/6/14 ecs 251, spring 2014 21 •

UCDavis, ecs 251 Spring 2014 Serializability 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) 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 5/6/14 ecs 251, spring 2014 22

UCDavis, ecs 251 Spring 2014 operation conflict rules Operations of different Conflict transactions read No read write Yes l l Reason Because the effect of a pair of read operations does not depend on the order in which they are executed Because the effect of a read and a write operation depends on the order of their execution Because the effect of a pair of write operations depends on the order of their execution 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) 5/6/14 ecs 251, spring 2014 23

UCDavis, ecs 251 Spring 2014 l 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. 5/6/14 ecs 251, spring 2014 24

UCDavis, ecs 251 Spring 2014 Concurrency Control 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. l – locking – time-stamping – optimistic approach 5/6/14 ecs 251, spring 2014 25

UCDavis, ecs 251 Spring 2014 l Lock-based CC Two extra operations: – lock and unlock l The problem is where and when to put these new operations? ? 5/6/14 ecs 251, spring 2014 26

UCDavis, ecs 251 Spring 2014 (a) lock(X) R(X) W(X) unlock(X) lock(Y) R(Y) W(Y) unlock(Y) 5/6/14 (b) lock(Z) R(Z) unlock(Z) lock(Y) R(Y) W(Y) unlock(Y) lock(X) R(X) W(X) unlock(X) ecs 251, spring 2014 (c) lock(Y) R(Y) lock(Z) R(Z) W(Y) unlock(Y) W(Z) unlock(Z) 27

UCDavis, ecs 251 Spring 2014 lock(Z) R(Z) unlock(Z) lock(Y) R(Y) W(Y) unlock(Y) R(Y) lock(Z) R(Z) lock(X) R(X) W(X) unlock(X) W(Y) unlock(Y) W(Z) unlock(Z) lock(X) R(X) lock(Y) R(Y) W(Y) unlock(Y) W(X) unlock(X) 5/6/14 ecs 251, spring 2014 28

UCDavis, ecs 251 Spring 2014 Transaction Execution History time R(Z) R(Y) W(Y) a X Y b Y, Z Y R(Y) R(Z) R(X) W(Y) W(Z) R(X) R(Y) W(X) 5/6/14 ecs 251, spring 2014 29 c

UCDavis, ecs 251 Spring 2014 (a) lock(X) lock(Y) lock(Z) R(X) W(X) R(Y) W(Y) unlock(Z) unlock(Y) unlock(X) 5/6/14 (b) lock(X) lock(Y) lock(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) unlock(X) ecs 251, spring 2014 (c) lock(X) lock(Y) lock(Z) R(Y) R(Z) W(Y) W(Z) unlock(Y) unlock(X) 30

UCDavis, ecs 251 Spring 2014 (a) Lock(X) Lock(Y) R(X) W(X) R(Y) W(Y) unlock(X) unlock(Y) 5/6/14 (b) lock(X) lock(Y) lock(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) unlock(X) ecs 251, spring 2014 (c) lock(Y) lock(Z) R(Y) R(Z) W(Y) W(Z) unlock(Y) 31

UCDavis, ecs 251 Spring 2014 (a) lock(X) R(X) W(X) Lock(Y) Unlock(x) R(Y) W(Y) unlock(Y) 5/6/14 (b) lock(X) lock(Y) lock(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) unlock(X) ecs 251, spring 2014 (c) lock(Y) R(Y) Lock(z) R(Z) W(Y) Unlock(Y) W(Z) unlock(Z) 32

UCDavis, ecs 251 Spring 2014 (a) lock(X) R(X) W(X) Lock(Y) Unlock(x) R(Y) W(Y) unlock(Y) 5/6/14 (b) lock(X) lock(Y) lock(Z) R(Z) unlock(Z) R(Y) W(Y) unlock(Y) R(X) W(X) unlock(X) ecs 251, spring 2014 (c) lock(Y) R(Y) Lock(z) R(Z) W(Y) Unlock(Y) W(Z) unlock(Z) 33

UCDavis, ecs 251 Spring 2014 lock(X) lock(Y) lock(Z) R(Y) W(Y) R(X) W(X) unlock(Z) unlock(Y) a b c lock(Y) lock(Z) R(Y) R(Z) unlock(X) W(Y) W(Z) unlock(Y) R(X) W(X) R(Y) W(Y) unlock(X) 5/6/14 ecs 251, spring 2014 34

UCDavis, ecs 251 Spring 2014 l Two-Phase Locking Two-phase locking. 5/6/14 ecs 251, spring 2014 35

UCDavis, ecs 251 Spring 2014 l Strict Two-Phase Locking 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!! 5/6/14 ecs 251, spring 2014 36

Lock compatibility (read, write and commit locks) UCDavis, ecs 251 Spring 2014 For one object Lock already set 5/6/14 Lock to be set none read OK write OK commit OK read OK OK wait write OK wait commit wait ecs 251, spring 2014 37

UCDavis, ecs 251 Spring 2014 l l 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”. l Problem: how to assign the order among transactions? 5/6/14 ecs 251, spring 2014 38

UCDavis, ecs 251 Spring 2014 l 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. 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. 5/6/14 ecs 251, spring 2014 39

UCDavis, ecs 251 Spring 2014 Rule Operation conflicts for timestamp ordering 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. 2. write Tc must not write an object that has been written by any Ti where Ti >Tc this requires that Tc > write timestamp of the committed object. 3. read write Tc must not read an object that has been written by any Ti where Ti >Tc this requires that Tc > write timestamp of the committed object. 5/6/14 ecs 251, spring 2014 40

UCDavis, ecs 251 Spring 2014 5/6/14 (a) R(X) W(X) R(Y) W(Y) (b) R(Z) R(Y) W(Y) R(X) W(X) ecs 251, spring 2014 (c) R(Y) R(Z) W(Y) W(Z) 41

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 X Y Z R W 0 0 0 5/6/14 X Y Z ecs 251, spring 2014 R W 1 0 2 1 0 0 42

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y)= 3 R(Z)= 3 (1 > 0 == W(Y)) R(Y) = 3 (v 1<3 == R(Y)) X Y Z R(Y) = 3 (v 2<3) R W 1 0 2 1 0 0 5/6/14 (2 > 0 == W(Y)) X Y Z ecs 251, spring 2014 R W 1 3 3 1 0 0 43

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y)= 3 R(Z)= 3 R(Y) = 3 (1<3) R(Y) = 3 (2<3) W(Y)= 3 W(Z)= 3 W(Y) abort (1 < (R(Y) == 3)) W(Y) abort (2 < (R(Y) == 3)) R(X) W(X) 5/6/14 ecs 251, spring 2014 X Y Z R W 1 3 3 44

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(Y)= 3 R(Z)= 3 R(X) = 2 W(Y)= 3 W(Z)= 3 W(Y) = 3 Which one(s) will commit? 5/6/14 ecs 251, spring 2014 45

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(Y)= 3 R(Z)= 3 R(X) = 2 W(Y)= 3 W(Z)= 3 W(Y) = 3 5/6/14 ecs 251, spring 2014 46

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(Y)= 3 R(Z)= 3 R(X) = 2 W(Y)= 3 W(Z)= 3 W(Y) = 3 5/6/14 ecs 251, spring 2014 47

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(Y)= 3 R(Z)= 3 R(X) = 2 W(Y)= 3 W(Z)= 3 W(Y) = 3 5/6/14 ecs 251, spring 2014 48

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(Y)= 3 R(Z)= 3 R(X) = 2 W(Y)= 3 W(Z)= 3 W(Y) = 3 5/6/14 ecs 251, spring 2014 49

UCDavis, ecs 251 Spring 2014 start TS a = 1 R(X) = 1 W(X) = 1 TSstartb = 2 TSstartc = 3 R(Z) = 2 R(Y) = 2 W(Y) = 2 R(Y)= 3 R(Z)= 3 R(X) = 2 W(Y)= 3 W(Z)= 3 W(Y) = 3 5/6/14 ecs 251, spring 2014 50

UCDavis, ecs 251 Spring 2014 DNS Transactions T 1: begin query end transaction cs. ucdavis. edu x 123. google. com mail. yahoo. com transaction T 3: begin query update end transaction mail. yahoo. com x 123. google. com transaction T 2: begin query update end transaction cs. ucdavis. edu x 123. google. com transaction Consistent Name-IPAddr Mappings e. g. , web site upgrading 5/6/14 ecs 251, spring 2014 51

UCDavis, ecs 251 Spring 2014 OCC: Optimistic Concurrency Control Execute the Transaction logging Validation Commit or abort? ? 5/6/14 ecs 251, spring 2014 52

UCDavis, ecs 251 Spring 2014 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 close. Transaction 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. 5/6/14 ecs 251, spring 2014 53

UCDavis, ecs 251 Spring 2014 OCC Data Structure Object l Transaction l – Read. Set: objects read by T – Write. Set: objects written by T – Shadow Copies: copies of objects written by T but not yet committed (temporary copies) W Real W R 5/6/14 ecs 251, spring 2014 R 54

UCDavis, ecs 251 Spring 2014 l OCC Operations T. read (Object Obj) – add Obj to T. Read. Set – if Obj in T. Write. Set, return T. Copies(Obj) – otherwise return Real(Obj); l T. write (Object Obj, Value V) – add Obj to T. Write. Set – if Obj in T. Write. Set, update T. Copies(Obj) – otherwise, create T. Copies(Obj), and update it. 5/6/14 ecs 251, spring 2014 55

UCDavis, ecs 251 Spring 2014 How to Validate? ? Execute the Transaction logging Validation 5/6/14 ecs 251, spring 2014 56

UCDavis, ecs 251 Spring 2014 l How to Validate? ? Assign the Transaction number – similar to the TSO, but until the beginning of the validation phase. 5/6/14 ecs 251, spring 2014 57

UCDavis, ecs 251 Spring 2014 l How to Validate? ? 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, Tcurrent – Have Tcurrent 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 l “Backward Validation” “Serial Validation” 5/6/14 ecs 251, spring 2014 “Forward” “Parallel” 58

UCDavis, ecs 251 Spring 2014 Three Phases in OCC Working Validation Starting Time of the Transaction 5/6/14 ecs 251, spring 2014 Update Commit 59

UCDavis, ecs 251 Spring 2014 OCC transactions Working Validation Update T 1 Earlier committed transactions T 2 T 3 Transaction being validated Tcurrent active Later active transactions 5/6/14 1 active 2 ecs 251, spring 2014 60

UCDavis, ecs 251 Spring 2014 OCC transactions Working Validation Update T 1 Earlier committed transaction Transaction being validated Tcurrent active Later active transactions 5/6/14 1 active 2 ecs 251, spring 2014 61

UCDavis, ecs 251 Spring 2014 OCC transactions Earlier committed transaction T 2 Transaction being validated Tcurrent active Later active transactions 5/6/14 1 active 2 ecs 251, spring 2014 62

UCDavis, ecs 251 Spring 2014 OCC transactions Earlier committed transaction T 3 Transaction being validated Tcurrent active Later active transactions 5/6/14 1 active 2 ecs 251, spring 2014 63

UCDavis, ecs 251 Spring 2014 Which ones should we consider? Working Validation Update T 1 Earlier committed transactions T 2 T 3 Transaction being validated Tcurrent active Later active transactions 5/6/14 1 active 2 ecs 251, spring 2014 64

UCDavis, ecs 251 Spring 2014 OCC Conflict Detection Transactions entering the commit queue. l Conflicts: l – if T reads something that has been updated by “earlier” committed transactions. T R-set W-set 5/6/14 T R-set W-set T T R-set W-set committed ecs 251, spring 2014 T R-set W-set current 65

UCDavis, ecs 251 Spring 2014 Why not Write-Write conflicts? l WW conflicts: – In OCC, all the writes are performed in one shot (atomically)!! 5/6/14 ecs 251, spring 2014 66

UCDavis, ecs 251 Spring 2014 5/6/14 (a) W(X) W(Z) (b) W(Y) W(X) ecs 251, spring 2014 (c) W(Y) W(Z) 67

UCDavis, ecs 251 Spring 2014 (a) W(X) (b) (c) W(Y) W(X) W(Y) W(Z) 5/6/14 ecs 251, spring 2014 68

UCDavis, ecs 251 Spring 2014 (a) (b) (c) validation W(Y) W(X) validation W(Y) W(Z) validation W(X) W(Z) 5/6/14 ecs 251, spring 2014 69

UCDavis, ecs 251 Spring 2014 Validation of Transactions Backward validation of transaction Tv boolean valid = true; for (int Ti = start. Tn+1; Ti <= finish. Tn; Ti++){ if (read set of Tv intersects write set of Ti) valid = false; } Forward validation of transaction Tv boolean valid = true; for (int Tid = active 1; Tid <= active. N; Tid++){ if (write set of Tv intersects read set of Tid) valid = false; } 5/6/14 ecs 251, spring 2014 70

UCDavis, ecs 251 Spring 2014 An Optimization conflict T 92 R-set W-set T 97 R-set W-set T 101 T 102 R-set W-set committed T 103 R-set W-set current Problem: Read. Set (T 103) intersects with Write. Set (T 101) Assume that Write. Set (T 103) does NOT intersect with Read. Set (T 101) Do we have any hope NOT to abort T 103? 5/6/14 ecs 251, spring 2014 71

UCDavis, ecs 251 Spring 2014 An Optimization T 92 R-set W-set T 97 R-set W-set T 103 T 101 T 102 R-set W-set current committed Problem: Read. Set (T 103) intersects with Write. Set (T 101) Assume that Write. Set (T 103) does NOT intersect with Read. Set (T 101) Do we have any hope NOT to abort T 103? 5/6/14 ecs 251, spring 2014 72

UCDavis, ecs 251 Spring 2014 l Forward Validation Try to detect conflicts for other transactions against Tcurrent – Have Tcurrent updated anything that have been read EVER? – Validate against all the transactions not yet committed. l 5/6/14 Every Object should have a “Read. Set” (which transactions have read this object). ecs 251, spring 2014 73

UCDavis, ecs 251 Spring 2014 OCC - Serial Validation committed committing Latest Committed transaction 5/6/14 working/in progress transaction number being assigned ecs 251, spring 2014 74

UCDavis, ecs 251 Spring 2014 l Parallel Validation Can I validate multiple transactions at the same time? 5/6/14 ecs 251, spring 2014 75

UCDavis, ecs 251 Spring 2014 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, Tcurrent – Have Tcurrent 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. 5/6/14 ecs 251, spring 2014 76

UCDavis, ecs 251 Spring 2014 OCC - Parallel Validation committed committing …. . working/in progress transaction number being assigned Latest Committed transaction difference: against themselves as well committing abc acb bac bca cab cba ab ba 5/6/14 ecs 251, spring 2014 77

UCDavis, ecs 251 Spring 2014 OCC - PV committed committing …. . Latest Committed transaction 5/6/14 working/in progress transaction number being assigned ecs 251, spring 2014 78

UCDavis, ecs 251 Spring 2014 l l l OCC the scheme is called optimistic because the likelihood of two transactions conflicting is low a transaction proceeds without restriction until the close. Transaction (no waiting, therefore no deadlock) it is then checked to see whether it has come into conflict with other transactions when a conflict arises, a transaction is aborted each transaction has three phases 5/6/14 ecs 251, spring 2014 79 •

UCDavis, ecs 251 Spring 2014 l Validation of transactions We use the read-write conflict rules – to ensure a particular transaction is serially equivalent with respect to all other overlapping transactions each transaction is given a transaction number when it starts validation (the number is kept if it commits) the rules ensure serializability of transaction Tv (transaction being validated) with respect to transaction Ti l l Tv Ti Rule write read 1. Ti must not read objects written by Tv forward read write 2. Tv must not read objects written by Ti backward write 3. Ti must not write objects written by Tv and Tv must not write objects written by Ti 5/6/14 ecs 251, spring 2014 • 80

OCC: UCDavis, ecs 251 Spring 2014 Optimistic Concurrency Control Execute the Transaction logging Concurrency? ? Security? ? Validation Semantic Conflict detection Intrusion detection Abort conflict resolution 5/6/14 ecs 251, spring 2014 81

AFS UCDavis, ecs 251 Spring 2014 State-ful clients and servers. l Caching the files to clients. l – File close ==> check-in the changes. l How to maintain consistency? – Using “Callback” in v 2/3 open read applications invalidate and re-cache 5/6/14 ecs 251, spring 2014 82

UCDavis, ecs 251 Spring 2014 Other Applications? ? l In what situations, the optimistic approach might be better than the traditional locking approach? 5/6/14 ecs 251, spring 2014 83

UCDavis, ecs 251 Spring 2014 l Special Cases Long-life transactions – ? ? ? l Read-only transactions – Maybe a very common case – Die versus Kill 5/6/14 ecs 251, spring 2014 84

UCDavis, ecs 251 Spring 2014 Multi-Versions Data update history for every object. l Every version has a logical timestamp l 5/6/14 ecs 251, spring 2014 85

UCDavis, ecs 251 Spring 2014 Multi-Versions X Y time 5/6/14 ecs 251, spring 2014 86

UCDavis, ecs 251 Spring 2014 Multi-Versions X Y Initial Value Real Time 5/6/14 ecs 251, spring 2014 87

UCDavis, ecs 251 Spring 2014 Multi-Versions X Y Initial Value Real Time 5/6/14 ecs 251, spring 2014 88

UCDavis, ecs 251 Spring 2014 MV -- Global VTS X Y Initial Value Virtual Time 5/6/14 ecs 251, spring 2014 89

UCDavis, ecs 251 Spring 2014 Real-Only Transaction l How to make sure that ROT will never be aborted? 5/6/14 ecs 251, spring 2014 90

UCDavis, ecs 251 Spring 2014 MV -- Global VTS X Y Initial Value Virtual Time 5/6/14 ecs 251, spring 2014 91

UCDavis, ecs 251 Spring 2014 MV -- Global VTS X C Y Initial Value Virtual Time 5/6/14 ecs 251, spring 2014 92

UCDavis, ecs 251 Spring 2014 Deciding the right “GTS” 5/6/14 ecs 251, spring 2014 93

UCDavis, ecs 251 Spring 2014 Deciding the right “GTS” 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? l 5/6/14 ecs 251, spring 2014 94

UCDavis, ecs 251 Spring 2014 Inactive Object 5/6/14 ecs 251, spring 2014 95

UCDavis, ecs 251 Spring 2014 Distributed OCC l Distributed Files systems 5/6/14 ecs 251, spring 2014 96

UCDavis, ecs 251 Spring 2014 local OCC on 1 server: Optimistic Concurrency Control Execute the Transaction logging Validation Abort conflict resolution 2 PC T R-set W-set 5/6/14 T R-set W-set T T T R-set W-set committed current ecs 251, spring 2014 97

UCDavis, ecs 251 Spring 2014 DOCC Transaction-ID: t. ID Validation-Order-ID: v. ID Server 1: [t. ID 67] [t. ID 17] [t. ID 05] [t. ID 22] R-set W-set committed [v. ID 03] [v. ID 05] [t. ID 34] R-set W-set current [v. ID 06] Server 2: [t. ID 67] [t. ID 17] [t. ID 34] [t. ID 05] R-set W-set committed [v. ID 11] [v. ID 12] [t. ID 22] R-set W-set current [v. ID 16] What is the issue here? 5/6/14 ecs 251, spring 2014 98

UCDavis, ecs 251 Spring 2014 DOCC Transaction-ID: t. ID Validation-Order-ID: v. ID Server X: [t. ID 67] [t. ID 17] [t. ID 05] [t. ID 22] R-set W-set committed [v. ID 03] [v. ID 05] [t. ID 34] R-set W-set current [v. ID 24/06] Server Y: [t. ID 67] [t. ID 17] [t. ID 34] [t. ID 05] R-set W-set committed [v. ID /24/11] [v. ID 12] [t. ID 22] R-set W-set current [v. ID 16] Local serializable, but not global serializable!! 5/6/14 ecs 251, spring 2014 99

UCDavis, ecs 251 Spring 2014 l Distribited OCC How to extend OCC to a distributed system? – distributed 3 phases: working, validation, and writing – how to coordinate? 5/6/14 ecs 251, spring 2014 100

UCDavis, ecs 251 Spring 2014 Distributed OCC Coordinator Server OCC OCC Coordinator …. . Server OCC What is the problem? How to assign “consistent” transaction # to the same global transaction? 5/6/14 ecs 251, spring 2014 101

UCDavis, ecs 251 Spring 2014 Maximum Validation ID Coordinator Server [mv. ID] Coordinator …. . Server [mv. ID] mv. ID: the largest validation-ID being assigned on a local server!! 5/6/14 ecs 251, spring 2014 102

UCDavis, ecs 251 Spring 2014 l Getting the v. ID Right!! C S – What is the current value of [mv. ID]? l S C – Answer l C S – C chooses a value (max{mv. IDi} + delta) l S C – success or not l C S – validation start if all succeed. 5/6/14 ecs 251, spring 2014 103

UCDavis, ecs 251 Spring 2014 SCSP: Server Cache Synchronization Protocol l l Consistency Updates among a set of processes connecting via a virtual network topology. One “originator” or “owner” and multiple “readers”. Eventually consistent or converge to the newest update! Using “sequence #” and strong checksum to distinguish new or old. Using “distributed reset” to handle maximum sequence #. 5/6/14 ecs 251, spring 2014 104

UCDavis, ecs 251 Spring 2014 SCSP – “Robust” Flooding Originator LS (Local Server) DCS (Directly Connected Server) 5/6/14 ecs 251, spring 2014 105

UCDavis, ecs 251 Spring 2014 Which one is Fresher? Seq#: seq 1 Cache: XYZ Originator: Alice Chech. Sum: cs 1 Seq#: seq 2 Cache: XYZ Originator: Alice Chech. Sum: cs 2 seq 1 > seq 2 seq 1 == seq 2 cs 1 > cs 2 5/6/14 ecs 251, spring 2014 106

UCDavis, ecs 251 Spring 2014 SCSP – Detecting and Correcting #23 Originator #23 #23 LS (Local Server) DCS (Directly Connected Server) 5/6/14 ecs 251, spring 2014 107

UCDavis, ecs 251 Spring 2014 SCSP – Detecting and Correcting #23 #37 #38 #23 #38 Originator #23 #37 #38 #23 LS (Local Server) DCS (Directly Connected Server) 5/6/14 ecs 251, spring 2014 108

UCDavis, ecs 251 Spring 2014 Distributed Reset 0 … 255 reset 0. . Originator LS (Local Server) DCS (Directly Connected Server) 5/6/14 ecs 251, spring 2014 109

UCDavis, ecs 251 Spring 2014 DMV-OCC l (Work) Obtain the GLOBAL version # – What is the latest Global Version # that I should use for this transaction? – We might need to know which OBJECTS we will need to access! l (Validation) Obtain the GLOBAL ID # – Representing the GLOBAL validation sequence 5/6/14 ecs 251, spring 2014 110

UCDavis, ecs 251 Spring 2014 Readings OCC (Kung-Robinson) l DMV-OCC l 5/6/14 ecs 251, spring 2014 111