CS162 Section
description
Transcript of CS162 Section
![Page 1: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/1.jpg)
CS162 Section
Lecture 10
Slides based from Lecture and www.news.cs.nyu.edu/~jinyang/fa08/
![Page 2: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/2.jpg)
What is conflict equivalence?
![Page 3: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/3.jpg)
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)
![Page 4: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/4.jpg)
T1 T2
ADependency graph
B
T1:R(A),W(A), R(B),W(B)T2: R(A),W(A), R(B),W(B)
![Page 5: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/5.jpg)
T1:R(A),W(A), R(B),W(B)T2: R(A),W(A),R(B),W(B)
T1 T2
A
B
Dependency graph
![Page 6: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/6.jpg)
2 Phase Locking1) 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”
1 3 5 7 9 11 13 15 17 190
1
2
3
4
Time
# Lo
cks
Hel
d GrowingPhase
ShrinkingPhase
![Page 7: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/7.jpg)
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?
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);
2 PL Example
![Page 8: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/8.jpg)
2 PL Example
![Page 9: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/9.jpg)
What if you used strict 2 PL?
![Page 10: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/10.jpg)
Why 2PC?
Most of the real time transactions
are distributed transactions.
A distributed transaction involves
altering data on multiple databases
A database must coordinate the committing or
rolling back of the changes in a transaction
![Page 11: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/11.jpg)
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
![Page 12: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/12.jpg)
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
![Page 13: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/13.jpg)
2PC contd…
16
director actors
actors
actors
RM
RM
director
Commit
Ready
CommitCommit
TM: Transaction ManagerRM: Resource Manager
client TM RM
Ready?
![Page 14: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/14.jpg)
Do you remember the State Machine of Coordinator from the lecture?
INIT
WAIT
ABORT COMMIT
Recv: VOTE-ABORTSend: GLOBAL-ABORT
Recv: VOTE-COMMITSend: GLOBAL-COMMIT
Recv: STARTSend: VOTE-REQ
![Page 15: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/15.jpg)
State Machine of workers
INIT
READY
ABORT COMMIT
Recv: VOTE-REQSend: VOTE-ABORT
Recv: VOTE-REQSend: VOTE-COMMIT
Recv: GLOBAL-ABORT Recv: GLOBAL-COMMIT
![Page 16: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/16.jpg)
Example
Bank A Bank B
Transfer $1000From A:$3000To B:$2000
• Clients want all-or-nothing transactions– Transfer either happens or not at all
client
![Page 17: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/17.jpg)
Strawman solution
Bank A Bank B
Transfer $1000From A:$3000To B:$2000
client
Transactioncoordinator
![Page 18: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/18.jpg)
Strawman solution
• What can go wrong?– A does not have enough money– B’s account no longer exists– B has crashed– Coordinator crashes
client transactioncoordinator
bank A bank B
start
doneA=A-1000
B=B+1000
![Page 19: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/19.jpg)
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
![Page 20: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/20.jpg)
Correctness firstclient transaction
coordinatorbank A bank B
start
result
prepare
prepare
rB
rA
outcomeoutcome
If rA==yes && rB==yes outcome = “commit”else outcome = “abort”
B commits uponreceiving “commit”
![Page 21: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/21.jpg)
Performance OverheadTM LOG Message RM Log
PREPARE
Prepare / abort
VOTE Y/N
Commit / abort
C/A
Commit / abort
ACK
End*
![Page 22: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/22.jpg)
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?
![Page 23: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/23.jpg)
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?
![Page 24: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/24.jpg)
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?
![Page 25: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/25.jpg)
What would happen if a single GLOBAL-COMMIT message
was lost?
![Page 26: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/26.jpg)
When can the TM respond with a SUCCESS?
client transactioncoordinator
bank A bank B
start
result
prepare
prepare
rB
rA
outcomeoutcome
![Page 27: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/27.jpg)
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
![Page 28: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/28.jpg)
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?
![Page 29: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/29.jpg)
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
![Page 30: CS162 Section](https://reader036.fdocuments.us/reader036/viewer/2022070504/56816695550346895dda7b89/html5/thumbnails/30.jpg)
Summary: two-phase commit
1. All nodes that decide reach the same decision2. No commit unless everyone says "yes".3. No failures and all "yes", then commit.4. If failures, then repair, wait long enough for
recovery, then some decision.