Distributed Transactions: Two-Phase Commit Protocol and Deadlock Detection - Prof. Sayan M, Study notes of Electrical and Electronics Engineering

Download Distributed Transactions: Two-Phase Commit Protocol and Deadlock Detection - Prof. Sayan M and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!

CS 425 / ECE 428

Distributed Systems

Lecture 22

Distributed Transactions

Chapter 14

sayan mitra

Distributed Transactions

Chapter 14

Coordination in Distributed Transactions

Each server has a special participant process.

Coordinator process (leader) resides in one of the servers, talks to trans. & participants.

T

A

Y

Z

B

C

D

X

join

join

join

Coordinator (^) Participant

Participant

Participant

T

Open^ Coordinator Transaction TID Close Transaction Abort Transaction

A Participant

a.method (TID )

1

2

Join (TID, ref)

3

Coordinator & Participants The Coordination Process

Distributed banking transaction

..

BranchZ

BranchX

participant

participant

C D

Client

BranchY

B

A

join participant

join

join

T

a.withdraw(4);

c.deposit(4);

b.withdraw(3);

d.deposit(3);

openTransaction

b.withdraw(T, 3);

closeTransaction

T = openTransaction a.withdraw(4); c.deposit(4); b.withdraw(3); d.deposit(3); closeTransaction

Note: the coordinator is in one of the servers, e.g. BranchX

Atomic Commit Protocols

 Consensus, but it’s impossible in asynchronous networks!

 So, need to ensure safety property in real-life implementation.

 In a one-phase commit protocol, the coordinator communicates

either commit or abort, to all participants until all acknowledge.

Doesn’t work when a participant crashes before receiving this message (partial transaction results are lost).

Does not allow participant to abort the transaction, e.g., under deadlock.

 In a two-phase protocol

 First phase involves coordinator collecting commit or abort vote from each

participant (which stores partial results in permanent storage).

 If all participants want to commit and no one has crashed, coordinator multicasts

commit message

 If any participant has crashed or aborted, coordinator multicasts abort message to

all participants

Operations for Two-Phase Commit

Protocol

canCommit?(trans)-> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote. doCommit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction. doAbort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction.

haveCommitted(trans, participant) Call from participant to coordinator to confirm that it has committed the transaction. getDecision(trans) -> Yes / No Call from participant to coordinator to ask for the decision on a transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages.

Communication in Two-Phase Commit Protocol

canCommit?

Yes doCommit

haveCommitted

Coordinator status

(waiting for votes)

3 committed done

1 prepared to commit

Participant status

(uncertain)

2 prepared to commit

4 committed

 To deal with (participant) server crashes

 Each participant saves tentative updates into permanent storage, right before

replying yes/no in first phase. Retrievable after crash recovery.

 To deal with canCommit? loss

 The participant may decide to abort unilaterally after a timeout (coordinator will

eventually abort)

 To deal with Yes/No loss, the coordinator aborts the transaction after a timeout

(pessimistic!). It must annouce doAbort to those who sent in their votes.

 To deal with doCommit loss

 The participant may wait for a timeout, send a getDecision request (retries until

reply received) – cannot abort after having voted Yes but before receiving doCommit/doAbort!

Two Phase Commit (2PC) Protocol

Coordinator (^) Participant

Execute

• Precommit

Uncertain

• Send request to each participant
• Wait for replies (time out possible)

Commit

• Send COMMIT to each participant

Abort

• Send ABORT to each participant

Execute

• Precommit
• send YES to coordinator
• Wait for decision

Abort

• Send NO to coordinator NO YES

canCommint? request not ready ready

All YES

Timeout or a NO

Commit

• Make transaction visible

Abort

COMMIT decision

CloseTrans()

ABORT decision

 Timeout based deadlock prevention is hard (why?)

 The wait-for graph in a distributed set of transactions is

held partially by each server

 To find cycles in a distributed wait-for graph, one option is

to use a central coordinator:

 Each server reports updates of its wait-for graph

 The coordinator constructs a global graph and checks for cycles

 Centralized deadlock detection suffers from usual comm.

overhead + bottleneck problems.

 In edge chasing, servers collectively make the global wait-

for graph and detect deadlocks :

 Servers forward “probe” messages to servers in the edges of wait -for graph, pushing the graph forward, until cycle is found.

Distributed Deadlocks

Probes Transmitted to Detect Deadlock

V

Held by

W

Held by Waits for

Waits for

Waits for Deadlock detected

U

C A

B

Initiation

W  U  V  W

W  U

W  U  V

Z

Y

X

V

U

W

Probes Transmitted to Detect Deadlock

V

Held by

W

Held by Waits for

Waits for

Waits for Deadlock detected

U

C A

B

Initiation

W  U  V  W

W  U

W  U  V

Z

Y

X

V

U

W

Transaction Priority

• Multiple servers may initiate and detect deadloacks
• In order to ensure that only one transaction in a cycle is aborted,

transactions are given priorities (e.g., inverse of timestamps) in such a

way that all transactions are totally ordered.

• When a deadlock cycle is found, the transaction with the lowest priority

is aborted. Even if several different servers detect the same cycle, only

one transaction aborts.

• Transaction priorities can be used to limit probe messages to be sent

only to lower prio. trans. and initiating probes only when higher prio.

trans. waits for a lower prio. trans.

• Caveat: suppose edges were created in order 3->1, 1->2, 2->3. Deadlock never detected.
• Fix: whenever an edge is created, tell everyone (broadcast) about this edge. May be inefficient.

Example 2PC in Nested Transactions

T

T

T

T

T

T

T

A

B

C

D

F

H

K

T

T

T

T

T

T

T

Nested Distributed Transaction

Abort No

Provisional^ Yes

Provisional Yes

Provisional Yes

Yes

Yes

Provisional

Abort^ No

Bottom up decision in 2PC

Distributed nested transactions

• When each sub-transaction was created, it joined its parent sub-transaction.
• The coordinator of each parent sub-transaction has a list of its child sub-

transactions.

• When a nested transaction provisionally commits, it reports its status and

the status of its descendants to its parent.

• When a nested transaction aborts, it reports abort without giving any

information about its descendants.

• The top-level transaction receives a list of all sub-transactions, together with

their status.