CSE 124 Lecture Notes - Lecture 18: Network Model, Failover, Unicast

38 views2 pages
Reasoning About Atomic Commit
WHY is this correct?
- Neither can commit unless BOTH agreed
What about performance?
1. Timeout - I’m up, but didn’t “receive” a message
Timeouts in Atomic Commit
Where do hosts wait for messages?
1. TC waits for “yes”or “no” from both A and B
- TC hasn’t sent any commit msgs, so can “safely” abort after timeout
- But this is conservative: might be a network problem
- We preserve correctness at the cost of performance!
Server Termination Protocol
Server B waits for commit or abort from TC
B “snoops” on server A and checks “status?” A then replies back to B
4 cases:
1. NO reply - B waits for TC
2. A received commit or abort from TC - Agree with decision
3. Server A hasn’t voted yet/voted NO - both abort
4. A voted yes - both must wait for the TC
Reasoning About STP
Safety: if servers don’t crash, ALL processes reach same decision
Liveness: if failures are “eventually” repaired, EVERY participant will eventually reach a decision
How to Handle Crash and Reboot?
- Can’t BACK out commit if already decided!
- use write-ahead log to record “commit!” and “yes” to disk
- “write ahead” actions that you THEN do later (all clients receive this action consistently)
Recovery Protocol w/ Non-Volatile State
If everyone rebooted AND is reachable, TC can just “check” for commit record on disk and
resend action
TC: if NO commit record on disk, abort
- No commit msgs
A, B: if no YES record on disk, abort
- TC could NOT have commited!
A, B: if YES record on disk, execute termination protocol
- Wait until TC makes decision, or contact peers for status
- This might block!
Introduction to Consensus
Unlock document

This preview shows half of the first page of the document.
Unlock all 2 pages and 3 million more documents.

Already have an account? Log in

Document Summary

Neither can commit unless both agreed: timeout - i"m up, but didn"t receive a message. Where do hosts wait for messages: tc waits for yes or no from both a and b. Tc hasn"t sent any commit msgs, so can safely abort after timeout. But this is conservative : might be a network problem. We preserve correctness at the cost of performance! Server b waits for commit or abort from tc. B snoops on server a and checks status? . Safety : if servers don"t crash, all processes reach same decision. Liveness : if failures are eventually repaired, every participant will eventually reach a decision. Can"t back out commit if already decided! Use write-ahead log to record commit! and yes to disk. If everyone rebooted and is reachable, tc can just check for commit record on disk and resend action. Tc: if no commit record on disk, abort. A, b: if no yes record on disk, abort.

Get access

Grade+20% off
$8 USD/m$10 USD/m
Billed $96 USD annually
Grade+
Homework Help
Study Guides
Textbook Solutions
Class Notes
Textbook Notes
Booster Class
40 Verified Answers
Class+
$8 USD/m
Billed $96 USD annually
Class+
Homework Help
Study Guides
Textbook Solutions
Class Notes
Textbook Notes
Booster Class
30 Verified Answers