Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Handling Failures & Recovery in Two-Phase Commit Protocol, Slides of Fundamentals of E-Commerce

Various aspects of the two-phase commit (2pc) protocol, including handling timeouts, forgetting transactions, logging state changes, and recovery procedures for both coordinators and participants. It also covers optimizations and variations such as read-only transactions, presumed abort, transfer of coordination, cooperative termination protocol, and phase zero.

Typology: Slides

2012/2013

Uploaded on 07/29/2013

sharad_984
sharad_984 🇮🇳

4.5

(13)

146 documents

1 / 15

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
2PC Failure Handling (contd)
A participant that voted Prepared times out waiting
for the coordinators decision
It’s blocked.
Use a termination protocol to decide what to do.
Naïve termination protocol - wait till the coordinator
recovers
The coordinator times out waiting for Done
it must resolicit them, so it can forget the decision
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download Handling Failures & Recovery in Two-Phase Commit Protocol and more Slides Fundamentals of E-Commerce in PDF only on Docsity!

2PC Failure Handling (cont’d)

-^

A participant that voted

Prepared

times out waiting

for the coordinator’s decision^ –

It’s blocked.

Use a termination protocol to decide what to do.

Naïve termination protocol - wait till the coordinatorrecovers

-^

The coordinator times out waiting for

Done

it must resolicit them, so it can forget the decision

Forgetting Transactions

-^

After a participant receives the decision, it mayforget the transaction

-^

After the coordinator receives

Done

from all

participants, it may forget the transaction

-^

A participant must not reply

Done

until its commit

or abort log record is stable^ –

Else, if it fails, then recovers, then asks the coordinatorfor a decision, the coordinator may not know

Coordinator Recovery

•^

If the coordinator fails and later recovers, it must know thedecision. It must therefore log^ –

the fact that it began T’s 2PC protocol, including the listof participants, and

Commit or Abort, before sending

Commit

or

Abort

to any

participant (so it knows whether to commit or abortafter it recovers).

•^

If the coordinator fails and recovers, it resends the decisionto participants from whom it doesn’t remember getting Done^ –

If the participant forgot the transaction, it replies

Done

The coordinator should therefore log Done after it hasreceived them all.

Participant Recovery

•^

If a participant P fails and later recovers, it first performscentralized recovery (Restart)

-^

For each distributed transaction T that was active at thetime of failure^ –

If P is not uncertain about T, then it unilaterally aborts T

If P is uncertain, it runs the termination protocol(which may leave P blocked)

-^

To ensure it can tell whether it’s uncertain, P must log itsvote before sending it to the coordinator

-^

To avoid becoming totally blocked due to one blockedtransaction, P should reacquire T’s locks during Restartand allow Restart to finish before T is resolved.

7.4 2PC Optimizations and Variations

-^

Optimizations^ –

Read-only transaction

Presumed Abort

Transfer of coordination

Cooperative termination protocol

-^

Variations^ –

Re-infection

Phase Zero

Read-only Transaction

-^

A read-only participant need only respond to phaseone. It doesn’t care what the decision is.

-^

It responds

Prepared-Read-Only

to

Request-to-Prepare

to tell the coordinator not to send the decision

-^

Limitation - All other participants must be fullyterminated, since the read-only participant willrelease locks after voting.^ –

No more testing of SQL integrity constraints

No more evaluation of SQL triggers

Docsity.com

Transfer of Coordination

If there is one participant, you can save a round of messages1. Coordinator asks participant to prepare and become the

coordinator.

  1. The participant (now coordinator) prepares, commits, and

tells the former coordinator to commit.

  1. The coordinator commits and replies Done.

Coordinator

Participant

Request-to-Prepare-and-transfer-coordination

Commit

Log commit

Log committed

Log prepared

Done

  • Supported by some app servers, but not in any standards.

Cooperative Termination Protocol (CTP)

-^

Assume coordinator includes a list of participants in Request-to-Prepare

•^

If a participant times-out waiting for the decision,it runs the following protocol.

  1. Participant P sends

Decision-Req

to other participants

  1. If participant Q voted

No

or hasn’t voted or received

Abort

from the coordinator, it responds

Abort

  1. If participant Q received

Commit

from the coordinator,

it responds

Commit

  1. If participant Q is uncertain, it responds

Uncertain

(or doesn’t respond at all).

-^

If all participants are uncertain, then P remains blocked.

Reinfection

•^

Suppose A is coordinator and B and C are participants^ –

A asks B and C to prepare

B votes prepared

C calls B to do some work. (B is reinfected.)

B does the work and tells C it has prepared,but now it expects C to be its coordinator.

When A asks C to prepare, C propagates the request to Band votes prepared only if both B and C are prepared.(See Tree of Processes discussion later.)

-^

Can be used to implement integrity constraint checking,triggers, and other commit-time processing, withoutrequiring an extra phase (between phases 1 and 2 of 2PC).

Phase Zero

•^

Suppose a participant P is caching transaction T’supdates that P needs to send to an RM (anotherparticipant) before T commits.^ –

P must send the updates after T invokes Commit, to ensure Phas all of T’s updates

P must send the updates before the RM prepares, to ensurethe updates are made stable during phase one. - Thus, we need an extra phase, before phase 1. -^

A participant explicitly enlists for phase zero.^ –

It doesn’t ack phase zero until it finishes flushing its cachedupdates to other participants.

-^

Supported in Microsoft DTC.