Skip to Content

Commit THIS, 2-Phase Nerds!

Here is a very short explanation to refresh your thoughts: 2PC consists of distributed databases running the same transaction by splitting it up into two phases. Contradictionary to the normal transaction, this one doesn’t work like the following:


DO Something()….


But rather, it has an additional step in the middle:


DO Something()…


IF (all_commited()== true)

(If you forgive my pidgin Java/SQL)

If you always wanted to know what a two phase commit (2PC) was, but never dared to ask, read the article by Armand Wilson Distributed Transactions and Two-Phase Commit, which explains this perfectly.

But Armand is too polite about the reasons why a 2PC is just unusable in a business environment.

Yes, my statement is this:

Two Phase Commit is unusable for business software.

There are two reasons why I say “unusable”:

1. A 2PC transaction depends on the assumption that the second phase of the commit will be successful. This is usually the case. But because you have to take care of unexpected situations as well, the literature of 2PC blows the whistle: once you get this deep into 2PC, you will find dirty descriptions of the method on how to solve such situations. The descriptions usually speak about “heuristic” methods to solve such a situation. I’d like you to take a moment and read the definition of “heuristic methods” from :


“Relating to or using a problem-solving technique in which the most appropriate solution of several found by alternative methods is selected at successive stages of a program for use in the next step of the program.”

More enlightening is the definition from the Free online dictionary of computing

Well, I might answer: I like clear statements.

You must be Logged on to comment or reply to a post.
  • Hi Benny,
    After reading your webpost and the link to the white paper, I am convinced of the difficulties of implementing two phase commit in distributed transactions.

    The article has been a great insight and I was not sure where to say thanks to Armand Wilson for that fantastic whitepaper.

    Subramanian V.

  • 2PC is a tool and like other tools, simple transactions for example, can be used well and achieve the desired results or can be used badly.

    All transaction success tends to depend on the timing around the holding of the recoverable resources. Even in a simple transaction, if you grab the locks earlier than you need to, you will cause locking conflict, potential deadlocks and "bad" application behaviour. True your data will be in sync but the user will keep getting their update transaction bounced. And in rare cases, simple transactions can also fail - commit/rollback involves lots of disk writes and the manager can crash mid-function with the logs and data being out of sync - usually this can be automatically resolved when the manager comes back up but sometimes operator intervention is requested - not frequent but it happens.

    2PC is built for a situation in which there is more than one resource to be recoverably managed, but for good behaviour the timing needs to be short. You only get in-doubt phase failures, the ones you are worried about, about as often as you get a failure in a simple transaction commit - in order to get one FIRST the database manager has to crash between saying OK to the prepare and getting the outcome - commit or abort AND the transaction coordinator has to be down when the resource manager comes up in recovery - pretty unusual in an enterprise data center. True the resolution at that point is tricky, but so is resolving the uncommited data from simple transactions when a database manager crashes.

    2PC works just fine - Dequeueing from MQ to update Oracle databases is a pretty popular scenario inside the enterprise and that uses 2PC. Where it becomes a pain is when the resources are distributed over a weaker network or the transaction is long lived - then the data stays in sync but the transactions fail a lot - 2PC works as advertised but not as desired.

    Using 2PC for loosely coupled Web Services would be inappropriate but it's legacy should have something to teach us. What 2PC does is tells resource managers how to behave and tells the transaction coordinator how to communicate. If loosely coupled Web Services, or any SOA, are going to achieve business integrity then we need for the individual service providers to understand how to behave and for coordination to be standarized. I don't think compensating transactions and 2PC are the same thing but they are family members with similar goals and protocols.

    2PC technical failure is very rare and a lot less scary than trying to rollforward recover multiple databases and queues to the same point in time. I think that 2PC should only be used when you need to, which is not very often, and agree strongly that WebServices is not one of those situations.

    Just not sure how you get from there to 2-phase is usuable for business applications - when there really is more than one resource to be changed and the application and resources are on the same machine or backbone, 2PC keeps both resources in sync with very, very low and managable short term and long term risk.

    But I admit to being a 2PC Nerd, so what else would I say 🙂


  • Hello Benny,

    the "one world, one database" philosophy simplifies interfacing, and indeed, a lot of interfaces can be argued to be asynchronous.

    Nevertheless, SAP itself delivers and excellent example, where a two phase commit would really make sense:

    Your document management & KPRO scenario:

    A 2PC would really be a great tool, to (better) ensure consistency between the application (document management), middleware (KPRO) and content server.

    I think anybody working in document management made the experience with destructed content files, not available content files, lost files after conversion etc. etc.

    Loosing ~0.5% percent of the content files without error messages by migrating to SAP-DMS/KPRO is an average figure.

    Of course the errors are of misc. nature (network, archive system ...), but I am expecting at least, that all errors are raised without comparing a million or more records (the SAP standard program provided to check the KPRO runs weeks in this case).

    To Benny only:
    In the opposite, I am a little less agressive. I am not telling you what I am thinking about this solution.

    Best regards,
    Stefan Kozlowski

    • Well Stefan ,
      if you don't mind, I was talking about business software. Of course, in any case when losing a transaction is not that dramatic, a 2PC system will work perfectly.
      The agressivenes of this article was targeted against those fellows who use the usual non-2PC ability of SAP by presenting 2PC as *the* ultimate solution to *business* problems - well knowing what they're doing.
      In the sales cycle technical features are very often used as feature list points and it wouldn't be the first time that a company is forced to implement a useless feature for the sake of being there, doing no good but driving up cost.
      Shouldn't that be more upsetting to you then missing this special feature in a very special case?
      • Hello Benny,

        definition of "business software" can be seen different, depending on your point of view. Seemless integration makes the border again fluent ...

        Tell an engineer, that the latest version of his drawing stored with CAD integration is now gone. Let's see, if this is dramatic 🙂

        Special case? The technogoly is used throughout the system (see generic object services). I think it is used much too often, to be a special case.

        Regarding to sales features lists, I understand and agree to your point.

        P.S. @Armand: Please do not believe, that the usage of a cell phone is highly illegal in Germany. It's a matter of the right tools: Use a headset.