1 / 102

ecs251 Fall 2007: Operating System Models #2: Transactions

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.

jonespeggy
Download Presentation

ecs251 Fall 2007: Operating System Models #2: Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Pre-proposal • handin wu ecs251_f2007_hw1 ecs251_f2007_hw1.tar.gz Transactions

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

  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,… Transactions

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

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

  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… Transactions

  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 Transactions

  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) Transactions

  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) Tb >> Tc >> Ta or “bca” Transactions

  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) Transactions

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. The Transaction Model Transactions

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. Lock-based CC • Two extra operations: • lock and unlock • The problem is where and when to put these new operations?? Transactions

  26. (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

  27. 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

  28. (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

  29. (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

  30. (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

  31. (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

  32. 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

  33. Two-Phase Locking • Two-phase locking. Transactions

  34. 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

  35. 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

  36. 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

  37. 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

  38. 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

  39. (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

  40. 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

  41. 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

  42. 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

  43. 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

  44. 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

  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 Transactions

  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 Transactions

  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 Transactions

  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 Transactions

  49. 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

  50. OCC: Optimistic Concurrency Control Execute the Transaction logging Validation Commit or abort?? Transactions

More Related