CS162 Section Lecture 10 Slides based from Lecture and jinyang/fa08

CS162 Section

Lecture 10

Slides 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)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 T2

ADependency graph

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)

T1 T2

A

B

Dependency graph

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

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

2 PL Example

What if you used strict 2 PL?

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

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

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

2PC contd…

16

director actors

actors

actors

RM

RM

director

Commit

Ready

CommitCommit

TM: Transaction ManagerRM: Resource Manager

client TM RM

Ready?

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

State Machine of workers

INIT

READY

ABORT COMMIT

Recv: VOTE-REQSend: VOTE-ABORT

Recv: VOTE-REQSend: VOTE-COMMIT

Recv: GLOBAL-ABORT Recv: GLOBAL-COMMIT

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

Strawman solution

Bank A Bank B

Transfer $1000From A:$3000To B:$2000

client

Transactioncoordinator

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

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

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”

Performance OverheadTM LOG Message RM Log

PREPARE

Prepare / abort

VOTE Y/N

Commit / abort

C/A

Commit / abort

ACK

End*

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?

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?

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?

What would happen if a single GLOBAL-COMMIT message

was lost?

When can the TM respond with a SUCCESS?

client transactioncoordinator

bank A bank B

start

result

prepare

prepare

rB

rA

outcomeoutcome

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

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?

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

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.