Atomic Commit Protocols PDF

# Atomic Commit Protocols ## Operations for two-phase commit protocol ### Participant interface * **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 coo...

# Atomic Commit Protocols ## Operations for two-phase commit protocol ### Participant interface * **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. ### Coordinator interface * **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. ## The Two-Phase Commit Protocol ### Phase 1 (voting phase) 1. The coordinator sends a canCommit? request to each of the participants in the transaction. 2. When a participant receives a canCommit? request it replies with its vote (Yes or No) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vote is No the participant aborts immediately. ### Phase 2 (completion according to outcome of vote) 3. The coordinator collects the votes (including its own). - If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a doCommit request to each of the participants. - Otherwise the coordinator decides to abort the transaction and sends doAbort requests to all participants that voted Yes. 4. Participants that voted Yes are waiting for a doCommit or doAbort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a haveCommitted call as confirmation to the coordinator. ## Two-Phase Commit Protocol (Diagram) The diagram shows the flow of messages in a two-phase commit protocol. * The coordinator sends a ```canCommit?``` request to each participant. * The participants reply with either a ```yes``` or ```no```. * If all participants vote ```yes```, the coordinator sends a ```doCommit``` request to each participant. * If any participant votes ```no```, the coordinator sends a ```doAbort``` request to each participant. ## TimeOut Protocol ### At Step 2 and 3 no commit decision made - **OK to abort.** - Coordinator will either not collect all commit votes or will vote for abort ### At Step 4 - **Cohort cannot communicate with coordinator.** - **Coordinator mayhave decided.** - **Cohort must block until communication re-established.** - **Might ask other cohorts.** - **Has decided, it just picks up from where it left off.** - **A cohort that crashed after voting commit, it must block until it discovers.** ## Blocking ### Blocking can occur if: - **Coordinator crashes** - **Cohort cannot communicate with coordinator.** - **Between 2 and 4.** ## Operations in coordinator for nested transactions * **openSubTransaction(trans) -> subTrans** - Opens a new subtransaction whose parent is trans and returns a unique subtransaction identifier. * **getStatus(trnas) -> committed, aborted, provisional** - Asks the coordinator to report on the status of the transaction trans. Returns values representing one of the following: committed, aborted, provisional. ### This is the interface of the coordinator of a subtransaction: - It allows it to open further subtransactions - It allows its subtransactions to enquire about its status. ### Client starts by using OpenTransaction to open a top-level transaction. - This returns a TID for the top-level transaction - The TID can be used to open a subtransaction - The subtransaction automatically joins the parent and a TID is returned. ## Transaction T decides whether T12 has provisionally committed and T11 has aborted, but the fate of T12 depends on its parent T1 and eventually on the top-level transaction, T. ### Although T21 and T22 have both provisionally committed, T2 has aborted and this means that T21 and T22 must also abort. ### Recall that: 1. A parent can commit even if a subtransaction aborts. 2. If a parent aborts, then its subtransactions must abort. ## Information held by coordinators of nested transactions - **Each coordinator has a list of its subtransactions.** - **At provisional commit, a subtransaction reports its status and the status of its descendents to its parent.** - **If a subtransaction aborts, it tells its parent.** **This document describes the different protocols used in atomic commit protocols and their advantages and disadvantages. It also discussed the different operations that are involved in these agreements.**