Talk:Two-phase commit protocol
From Wikipedia, the free encyclopedia
[edit] Merged in Two-phase commit
I just merged in the content from Two-phase commit. There was almost 100% overlap in content, though there were differences in terminology and formatting. I hope you all like the result. Jamie 01:12, 14 November 2005 (UTC)
The following paragraph in "Disadvantages" is incorrect and needs to be removed:
"Another disadvantage is the protocol is conservative. It is biased to the abort case rather than the complete case. Also it cannot recover from cases where a node has failed in the commit stage (due to internal or network failures) after indicating that it is ready to commit. In this case, resources that committed prior to this failure cannot be rolled back."
First, it can be biased either to commit or abort (see literature). Also, all known commercial implementations recover correctly (to abort) if such faliure occures. No resource commits before completion (decision by coordinator)
How can it be that "all known commercial implementations recover correctly (to abort) if such faliure occures [sic]?" At some point the coordinator must start calling the FINAL commits on all the participants, either all at once or one-at-a-time (same thing). If one of the partipants fails the final commit, won't the data be left in an inconsistent state? This is what the "resources that committed prior to this failure cannot be rolled back" is suggesting.
I believe this is a MAJOR question (really, "is 'two-phase commit' a magic bullet?") and even IF it is true that "all known commerical implementations recover correctly," I think that this magical point should be included in the article somehow. --Daniel Rosenstark 01:24, 12 June 2006 (UTC)
As per earlier comments, I wonder if more discussion could be given in the "Disadvantages" paragraph regarding what it actually means to be biased towards aborts rather than towards commits. Nels Beckman 19:11, 6 September 2006 (UTC)
I just modified the section on disadvantages, since it contained some mistakes. 1. The usual 2PC uses a timeout to avoid that the coordinator blocks forever. This is the reason why the protocol is biased towards aborts. 2. I removed the passage "Also it cannot recover from cases where a node has failed in the commit stage (due to internal or network failures) after indicating that it is ready to commit. In this case, resources that committed prior to this failure cannot be rolled back." This will never occur if the protocol is implemented properly: A cohort will only vote for commit if it can guarantee successful completion, even in the case of a failure. So, prior to voting for commit the cohort will log the necessary information for transaction redo. In addition, each cohort will keep the undo log until it has received the final decision by the coordinator. So, A cohort will never reveive an abort message without beeing prepared to abort.
