In browsing around the Web, as one occasionally does in a free nanosecond, I read an interesting article about twp-phase commit transactions by Gregor Hohpe of ThoughtWorks ("Your Coffee Shop Does Not Use Two Phase Commit"). Gregor comes at the subject from the direction opposite the one I usually take in this column, since I am of a TP persuasion, but he covers the same arguments that I have explored in the past and comes to similar conclusions.

"Your Coffee Shop Doesn't Use Two-Phase Commit": Should You?
Briefly, two-phase commit can be costly from a performance standpoint - in terms of both end-to-end transaction time and throughput - and you need to make sure you cost-justify your decision to use it when you do. On a finer point of detail, I would take issue with the implication in the article that there is a straight choice between synchronous processing and two-phase commit - most of the transaction systems I have ever seen involve access to one database and one asynchronous reliable queue in the context of a single transaction - thus guaranteeing that some updates happen and a message is guaranteed to be delivered to the next step in the process at some time in the future as an atomic unit, but that's another story.

So, back from my digression, the reason I wanted to write a follow-on to this article was because it seemed to me that the article illustrates a good point about the benefits of transactions and transaction management - particularly in the broadest sense of the term. To briefly summarize it so that the rest of my article makes sense, the thesis is that Starbucks uses an asynchronous model for accepting coffee requests into its main business system (the barista) in order to maximize the potential throughput of coffee from the shop, and hence maximize revenue. The potential cost of this optimization to the "happy day" scenario - the assumption that all is going forward with no errors - is the odd need to pause and hold up the line while wrong drinks are disposed of and remade, or money is refunded to unhappy (and still thirsty) punters. Indeed, if this is the only cost of this assumption, then the asynchronous case is clearly the correct design - throughput is maximized and the cost of unwinding the odd failure is outweighed by the less costly, less complex system we have built.

However, back in the real world away from analogy land, this is often a better "project phase one" argument than a "deployment lifetime" argument. To return to the analogy by way of illustration, imagine that our coffee production line is now in place and we are happily raking in money for strangely named coffees, and suddenly we get a good idea: How about improved quality of service for regular customers? For those really important coffee drinkers - rendered hyper-impatient by the caffeine they are wired with - we want to tell them how long it will be until they can expect their coffee. This poses a problem for us. From the moment a name got written on the empty coffee cup and it got queued on top of the coffee machine, we lost track of it. We are relying on the customer to hang about and wait until his name is called before customer and cup (now replete with coffee) are reunited. To track the cup in the queue, we will need to adopt a new strategy - maybe we have a yellow cup for the priority customer, so we can see the yellow cups processing up the queue. Well, that's fine until we have too many privileged customers, when we will no longer be able to distinguish which yellow cup we are looking for. What now? Suddenly we start to wish that we had a nice synchronous coffee production process, so we knew where we stood; of course, the analogy is starting to creak here a bit - the time it takes to produce a coffee is relatively short, and there is only one business system in the process, so this is not really that great an issue (which is a pity, because I was just about to propose attaching RFID tags to each cup, to allow us to associate them with their intended recipients…), but there is a core of truth here.

Attach an RFID Tag to Each Cup
Because of the apparent simplicity of asynchronous queuing-based systems, they are widely deployed. Additionally, a widely felt pain they create is the lack of visibility into "in-flight" business transactions. There is a clear and present demand for "executive dashboard" type facilities, so that managers have some insight into how the systems for which they are responsible are running - and some ability to foresee and forestall problems. This usually causes the nice simple phase one MOM-based systems to be glued to a lot of information gathering infrastructure (usually, more queues) with some kind of event correlation machinery on the back end to give an indication of what is passing through the system, and what looks unusual or possibly erroneous. Where did that original elegant simplicity go?

One oft-overlooked advantage of building systems with a transaction manager coordinating them is that we get an out-of-the-box central place that we can go to see which business event has touched which resource, and what the outcome is expected to be.

Of course, that said we still do have the bottleneck that the enforcement of ACID properties places on our throughput (chiefly, because of the database locks that ACID implies). It is here that I can mount another of my favorite hobbyhorses. One way to get the benefits of central coordination of transactions (in the loose sense, simply meaning correlated business activities) without incurring the penalties of data locking and contention is to relax the (technical) strictures of the ACID rules and allow a more easygoing, business reality-focused view of how the transactions correlate the business events. This is the idea behind a "next-generation" transaction concept such as cohesions, which first surfaced in the OASIS BTP standard and are now informing the debate within the WSBusinessActivity proposed standard.

Have Your Coffee and Drink It Too
Maybe, when these transaction standards mature, we will at last be able to have our coffee and drink it too?

References

• Hohpe, G. "Your Coffee Shop Does Not Use Two Phase Commit." www.eaipatterns.com/articles.html