O.k., it's pet peeve time. Otherwise intelligent people seem to get really confused whenever they hear "two phase commit". They immediately assume that if one is using two phase commits then one must be implementing an ACID or at least Atomic transaction. Nonsense! A two phase commit is nothing more than a coordination mechanism. It allows one to guarantee that a group of independent systems will either all perform or all not perform a particular action. Historically the 'action' was usually some kind of ACID or at least Atomic transaction. But there is nothing in two phase commits that requires or even implies any particular action, atomic, ACID or otherwise.
In fact, two phase commits are incredibly useful for the ultimate in non-ACID transactions – compensating transactions. In an ACID transaction if the attempted transaction fails then everything gets nicely cleaned up, no muss, no fuss. In a compensating transaction, on the other hand, if the action fails then an attempt is made to undo the action but with no ACID semantics. For example, if I book a flight with a travel agency and it turns out they couldn't book the flight they said they would then instead of just canceling the whole ticket (and losing their booking fee) they might rebook me on another flight that I may or may not prefer. The point being, that the 'failed' transaction (booking the agreed flight) is 'compensated' (by buying another flight) rather than rolled back in an ACID sense (by canceling the ticket and refunding the fees).
Now imagine that I want to book a whole trip myself involving a hotel, a rental car, a plane flight, etc. I could use a two phase commit protocol to allow me to first send reservation requests to each of the companies and then if I can't get reservation confirmations from everyone the two phase commit coordinator would automatically trigger a compensate command to each of the companies. Of course the compensation may not be what I like, i.e. the airline may charge me a re-booking fee, but them's the breaks in the real world.
The point is that two phase commit protocols are nothing more or less than a coordination mechanism and what they are coordinating may or may not be an ACID or Atomic transaction.
Actually 2PC only reduces the likelyhood of uncoordinated outcome. It is still possible (especially if the commit phase was not well designed with fault-tolerant little impact procedures in mind).
And your example is actually pretty good: real world scenarios often use 2PC with heuristic outcome determination since humans are pretty weak in follwing the protocol all the time :)
Bernd
You’re absolutely right, of course. 2PC can’t guarantee anything other than a well defined failure condition. But even the failure condition isn’t quite as useful as one might think because, at least in a time bounded situation, it may be impossible for any single player (including the coordinator) to know what state the other players ended up in. I talk about this a bit in a new article I’m writing on reliable messaging for SOA.
I agree with you that 2PC has nothing to do with transaction being ACID or not – however it is a fact that many have this connection carved in their mind…
We had the same issue when we working on OASIS Business Transaction Protocol (BTP) TC recently, well about 2 years ago – time flies. The BTP protocol is already long gone! “However the death of BTP, unlike that of Mark Twain, was always greatly understated”. BTP introduced a lot of new concepts related to new type of transactions. In BTP TC we talked on this topic for many long sessions and finally decided to use the term Two Phase Outcome (2PO) instead of Two Phase Commit (2PC) for the non atomic non ACID transactions since 2PC remind many, as you also mentioned, the ACID transactions. BTP used 2PC only in the context of atomic transactions with ACID characteristics otherwise used 2PO. BTP also abandoned to use the term Transaction for the non atomic ‘Transactions’ and use the term ‘Cohesion’ again for the same reason that the term Transactions remind many only ACID Atomic transactions – and database! I don’t mean to suggest using these terms, but it is clear that in the process and web services era the ‘transactions’ no longer only involve the consistency and recovery of data but also consistency and recovery of process that requires new protocols and new thinking.
.Sazi