Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
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
1 / 15
This page cannot be seen from the preview
Don't miss anything!
-^
It’s blocked.
Use a termination protocol to decide what to do.
Naïve termination protocol - wait till the coordinatorrecovers
-^
it must resolicit them, so it can forget the decision
-^
-^
-^
Else, if it fails, then recovers, then asks the coordinatorfor a decision, the coordinator may not know
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.
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.
-^
Read-only transaction
Presumed Abort
Transfer of coordination
Cooperative termination protocol
-^
Re-infection
Phase Zero
-^
-^
-^
No more testing of SQL integrity constraints
No more evaluation of SQL triggers
Docsity.com
If there is one participant, you can save a round of messages1. Coordinator asks participant to prepare and become the
coordinator.
tells the former coordinator to commit.
Coordinator
Participant
Request-to-Prepare-and-transfer-coordination
Commit
Log commit
Log committed
Log prepared
Done
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.
Decision-Req
to other participants
No
or hasn’t voted or received
Abort
from the coordinator, it responds
Abort
Commit
from the coordinator,
it responds
Commit
Uncertain
(or doesn’t respond at all).
-^
If all participants are uncertain, then P remains blocked.
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).
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.
