1.02k likes | 1.04k Views
ecs251 Fall 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. Pre-proposal. handin wu ecs251_f2007_hw1 ecs251_f2007_hw1.tar.gz. Transaction.
E N D
ecs251 Fall 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 Transactions
Pre-proposal • handin wu ecs251_f2007_hw1 ecs251_f2007_hw1.tar.gz Transactions
Transaction • A sequence/program of operations {read, write} on a set of “shared” variables Transactions
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,… Transactions
Applications of Transactions • Database/Information System • Distributed Mobile computing • Distributed File System • Fault Tolerant computing Transactions
Transaction Properties: ACID • Atomicity (all or nothing) • Consistency (consistent state transition) • Isolation (intermediate results) • Durability (persistent) Transactions
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… Transactions
(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 Transactions
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) Transactions
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” Transactions
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) Transactions
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) Transactions
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) Transactions
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) Transactions
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) Transactions
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) Transactions
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. Transactions
The Transaction Model Transactions
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 Transactions
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). • Transactions
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 Transactions
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 Transactions
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. Transactions
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 Transactions
Lock-based CC • Two extra operations: • lock and unlock • The problem is where and when to put these new operations?? Transactions
(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) Transactions
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) Transactions
(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) Transactions
(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) Transactions
(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) Transactions
(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) Transactions
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 Transactions
Two-Phase Locking • Two-phase locking. Transactions
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!! Transactions
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) Transactions
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? Transactions
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. Transactions
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 Transactions
(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) Transactions
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 Transactions
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 Transactions
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 Transactions
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? Transactions
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 Transactions
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 Transactions
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 Transactions
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 Transactions
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 Transactions
DNS Transactions 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 Consistent Name-IPAddr Mappings e.g., web site upgrading Transactions
OCC: Optimistic Concurrency Control Execute the Transaction logging Validation Commit or abort?? Transactions