Talk:Three-phase commit protocol

message: I have removed large parts of the article and corrected the citation of the seminal report by Skeen, which was incorrectly a reference to a follow-up theoretical analysis by Skeen and Stonebraker.
The claims made in the previous version of the Wikipedia article were theoretically unsound, and I wasted quite some time trying to convince myself otherwise, until I finally gave up and read the original papers. It is not possible to place an upper bound on the time it takes to resolve a distributed transaction without violating the basic soundness criterion, as the Wikipedia article previously claimed. This would imply that one could solve the two generals problem in finite time. Indeed, it wasn't hard to find an example of a network partitioning where the timeout-based protocol would cause two cohorts to respectively commit and abort the same transaction. This eliminates the whole point of the protocol to begin with, as it is no better than just sending the transaction to all cohorts and hoping for the best.
I haven't replaced the description with a better one. The seminal technical report by Skeen is publicly available and very readable, and I don't think I can describe it any better than him. Note in particular that his description does not involve the use of timeouts at all: it is a quorum based algorithm, and timeouts would be an implementation detail used to detect failures.
Ulrik Rasmussen (talk) 08:52, 10 October 2019 (UTC)

message: Since this is the first time that I post a message to a wikipedia discussion, I won't edit the article myself. I suggest this to the original author. Please correct me if I'm wrong!
You could make the two-phase commit protocol non-blocking in the same way as with the three-phase: by introducing timeouts. The problem with both the blocking and the non-blocking variant is the same: you can never be sure of the atomicity.
Consider the . If Cohort(i) sends an ACK message that gets lost because the link to Cohort breaks, the Cohort will timeout and commit the local transaction, while the Coordinator, not having received the ACK, will timeout and abort. Even if the link gets restored, you can't abort (rollback) later on the commited part on the Cohort.
The basic problem with most kinds of commit protocols is called the Two_Generals%27_Problem. If you add more and more layers of acknowledgements (acknowledgements to acknowledgements), the system gets more reliable but never perfect. On the down side, the execution slows more and more.
Regards,
Igorecan 13:14, 11 April 2006 (UTC)
thread_title:  Atomicity reliability 

message: The figure is nice, but is inconsistent with the text, in that it shows "participants" rather than "cohorts".  —Preceding unsigned comment added by Yagibear (talk • contribs) 22:51, 31 October 2007 (UTC)
replies: text: Ah, good point. I'll update it sometime within the next few days. If I forget, feel free to send me an email to remind me. --Tjohns  ✎ 18:46, 11 March 2008 (UTC)
replies: text:  Feel free to let me know if any other changes need to be made. Tjohns  ✎ 06:49, 21 March 2008 (UTC)
thread_title:  Figure 

message: I wanted to use this article as a brief introduction to the kinds of problems that must
be considered in distributed consensus, but was disappointed by the brevity of the 
explanation of how this is an improvement over the two-phase commit.  I think the
discussion is fine as a definition for those already familiar with the domain, but
needs a little more justification for pedagogical use.  I will take a shot at this,
and would welcome improvement from anyone.
MarkKampe (talk) 18:55, 13 March 2010 (UTC)
thread_title:  modes of failure