1 / 30

CS162 Section

CS162 Section. Lecture 10 S lides based from Lecture and www.news.cs.nyu.edu /~jinyang/fa08 /. What is conflict equivalence?. Conflict Serializability. T1:R(A),W(A), R(B),W(B) T2: R(A),W(A), R(B),W(B) . T1:R(A),W(A), R(B), W(B)

wendi
Télécharger la présentation

CS162 Section

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. CS162 Section Lecture 10 Slides based from Lecture and www.news.cs.nyu.edu/~jinyang/fa08/

  2. What is conflict equivalence?

  3. Conflict Serializability T1:R(A),W(A), R(B),W(B) T2: R(A),W(A), R(B),W(B) T1:R(A),W(A), R(B), W(B) T2: R(A), W(A), R(B),W(B) T1:R(A),W(A),R(B), W(B) T2: R(A),W(A), R(B),W(B)

  4. A T1:R(A),W(A), R(B),W(B) T2: R(A),W(A), R(B),W(B) B Dependency graph T1 T2

  5. A B T1:R(A),W(A), R(B),W(B) T2: R(A),W(A),R(B),W(B) T1 T2 Dependency graph

  6. 2 Phase Locking 1) Each transaction must obtain: • S (shared) or X (exclusive) lock on data before reading, • X (exclusive) lock on data before writing 2) A transaction can not request additional locks once it releases any locks Thus, each transaction has a “growing phase” followed by a “shrinking phase” Growing Phase Shrinking Phase

  7. Assume each instruction (R, W, etc) takes one time unit, and lock ops takes zero time units. What is the minimum possible execution time schedule? 2 PL Example Transaction 1: R(A); A = A + 100; W(A); R(B); B = B – 100; W(B); Transaction 2: R(A); A = A – 50; W(A);

  8. 2 PL Example

  9. What if you used strict 2 PL?

  10. Why 2PC?

  11. Failures in a distributed system • Consistency requires agreement among multiple servers • Is transaction X committed? • Have all servers applied update X to a replica? • Achieving agreement w/ failures is hard • Impossible to distinguish host vs. network failures

  12. Two Phase commit (2PC) • It is a standard protocol for making commit and abort atomic • Coordinator - the component that coordinates commitment at home(T) • Participant - a resource manager accessed by T • A participant P is ready to commit T if all of T’s after-images at P are in stable storage

  13. TM client 2PC contd… director RM director actors RM actors actors RM Commit Ready? Ready Commit Commit TM: Transaction Manager RM: Resource Manager

  14. Do you remember the State Machine of Coordinator from the lecture? INIT Recv: START Send: VOTE-REQ WAIT Recv: VOTE-ABORT Send: GLOBAL-ABORT Recv: VOTE-COMMIT Send: GLOBAL-COMMIT ABORT COMMIT

  15. State Machine of workers INIT Recv: VOTE-REQ Send: VOTE-ABORT Recv: VOTE-REQ Send: VOTE-COMMIT READY Recv: GLOBAL-ABORT Recv: GLOBAL-COMMIT ABORT COMMIT

  16. Example • Clients want all-or-nothing transactions • Transfer either happens or not at all • Transfer $1000 • From A:$3000 • To B:$2000 client Bank A Bank B

  17. Strawman solution • Transfer $1000 • From A:$3000 • To B:$2000 Transaction coordinator client Bank A Bank B

  18. Strawman solution transaction coordinator bank A bank B client • What can go wrong? • A does not have enough money • B’s account no longer exists • B has crashed • Coordinator crashes start A=A-1000 done B=B+1000

  19. Reasoning about correctness • TC, A, B each has a notion of committing • Correctness: • If one commits, no one aborts • If one aborts, no one commits • Performance: • If no failures, A and B can commit, then commit • If failures happen, find out outcome soon

  20. Correctness first transaction coordinator bank A bank B client start prepare prepare rA rB outcome outcome result If rA==yes && rB==yes outcome = “commit” else outcome = “abort” B commits upon receiving “commit”

  21. Performance Overhead

  22. Performance Issues • What about timeouts? • TC times out waiting for A’s response • A times out waiting for TC’s outcome message • What about reboots? • How does a participant clean up?

  23. Handling timeout on A/B • TC times out waiting for A (or B)’s “yes/no” response • Can TC unilaterally decide to commit? • Can TC unilaterally decide to abort?

  24. Handling timeout on TC • If B responded with “no” … • Can it unilaterally abort? • If B responded with “yes” … • Can it unilaterally abort? • Can it unilaterally commit?

  25. What would happen if a single GLOBAL-COMMIT message was lost?

  26. transaction coordinator When can the TM respond with a SUCCESS? bank A bank B client start prepare prepare rA rB outcome outcome result

  27. Handling crash and reboot • Nodes cannot back out if commit is decided • TC crashes just after deciding “commit” • Cannot forget about its decision after reboot • A/B crashes after sending “yes” • Cannot forget about their response after reboot

  28. Handling crash and reboot • All nodes must log protocol progress • What and when does TC log to disk? • What and when does A/B log to disk?

  29. Recovery upon reboot • If TC finds no “commit” on disk, abort • If TC finds “commit”, commit • If A/B finds no “yes” on disk, abort • If A/B finds “yes”, run termination protocol to decide

  30. Summary: two-phase commit • All nodes that decide reach the same decision • No commit unless everyone says "yes". • No failures and all "yes", then commit. • If failures, then repair, wait long enough for recovery, then some decision.

More Related