Response to Gregor on transactions

Update June 7: I realized after I published this that I forgot to thank Gregor for his kind words about IONA. As long as I’m at it I should also have added that it strikes me that Gregor is a “right tool for the job” kind of guy, too.
Gregor has posted a very interesting reply to part of my entry about his presentation on InfoQ.
I don’t see a place to post a comment on his blog so I will answer here.
I did read through the Starbucks piece before, probably a year or so ago, and it is a nice explanation of why transactions aren’t needed in some situations. I also realize it is just an analogy to illustrate a good point (i.e. don’t automatically think you need transactions, use them appropriately etc.). I am a “right tool for the job” type person so I completely agree with him on that.
But I started thinking about it again after watching the presentation and it struck me that it was a bit like suggesting that you would consider using transactions to run a crane or something. Transactions are designed to capture data about something in the real world, not to interact with the real world directly. So of course you wouldn’t use transactions to serve coffee.
Anyway, I think one of the reasons I reacted to it a bit differently when he brought it up in the presentation (which I still absolutely recommend watching) is that there’s been a lot of negative stuff about transactions lately – and this just as I’ve been finishing up about 5 years of work on the specifications for Web services transactions. I think transactions are being misrepresented as something evil for an SOA environment, which they are not.
I really hope I am not guilty of being too religious about this stuff just because I’ve been working on it for a long time 😉 But I really think that transactions should not be dismissed as inappropriate for SOA without first evaluating whether or not you need them, or would benefit from them. And to do that it’s necessary to understand what transactions were designed for, and how they should be used appropriately.
It is definitely interesting to see some of the alternatives being proposed. Mark Little and I proposed one ourselves in the WS-CAF work – one that supports the federation of different transation models, and is designed to support long running asynchronous environments like those in loosely coupled SOA and BPM types of deployments. As far as we could tell though no one seemed very interested in it, and we’ve just sort of let the spec sit there.
I find it hard to believe (in following one of the links Gregor posted) that eBay doesn’t use any transactions at all, but I haven’t had time to really read through everything yet. I can certainly believe they don’t use distributed transactions, but database transactions are pretty fast. Anyway, I will finish reading up on those things – thanks for the pointers. This comes at a good time because Phil and I are trying to finish up the second edition of Principles of Transaction Processing
ps Gregor – the reason I didn’t meet you at this year’s Microsoft MVP Summit is that I could only attend the first day and a half…maybe next time!

5 responses to “Response to Gregor on transactions

  1. Eric, can you comment on this characterization of transactions broken down by scope?

    Distributed transactions that cover updates to all data accessed during a “client” side operation (or business operation>.
    Service level transactions that cover a single service and message processing.
    Entity level transactions in the sense that Pat Helland means here.

    It seems to me that the WS-* specs are trying to bridge the gap between the first two types.
    Thanks, John

  2. Hi John,
    Thanks for the pointer to Pat’s paper. I have only had a chance to skim through it. Hopefully I will find time to read it carefully soon.
    I am not sure therefore that I will be able to answer your question correctly in that context, but here goes.
    The three specs in WS-TX are designed to provide:
    1) An abstraction of the coordinator concept (WS-C) in which the coordinator basically becomes a generic state machine onto which you can map multiple transaction protocol types
    2) A classic “2PC” protocol type mapped to the generic coordinator, the purpose of which is to achieve interoperability across existing transaction managers (i.e. the WS-AT spec is not defining anything new but rather an interoperability mechanism using Web services, e.g. OTS/JTS to DTC)
    3) A new compensation based protocol designed for long-running transactions such as BPEL flows (WS-BA) that is also sometimes called “open nested transactions” because it allows a nested transaction to commit independently of the parent (and then triggers a compensation should the parent roll back)
    These specs are not really trying to define any application models and do not really address the issue of “scopes” as it appears to be defined in Pat’s paper.
    Pat seems to be looking for alternatives to the classic 2PC protocol for loosely-coupled systems. Such alternatives could be defined as protocol sets on top of WS-C.
    I am not sure what is meant by client side transactions here. I am personally not a believer in such a thing – meaning I do not consider a transaction to be started until a resource manager is accessed and its state changed (up to that point nothing significant has happened that requires the transaction mechanism).
    I am also not exactly sure what is meant by service level transactions. The protocols in WS-TX are pretty generic and designed for (a) interoperability across existing TMs and (b) for BPEL flow type compensations. A classic use case for the WS-AT protocol would be to coordinate a transaction between a service requester and a service provider, assuming the requester and provider were updating the state of different transactional resource managers.
    One of the most common use cases for 2PC is coordinating a queue update operation with a database update operation, and while it would be possible to define this using WS-AT it would seem more appropriate for a local TM to just handle this on its own without involving the Web services stack – unless the invocatoin on both queue and database are done using separate Web services.
    I will try to get back to this later and add more thoughts after finishing Pat’s article.

  3. Ok, I’ve read through more of Pat’s article, and it is definitely very interesting.
    It is all about using “local” transactions associated with a scope, so I would say that WS-TX does not really apply.
    I understood the primary motivation of Pat’s paper to explore scenarios for “near infinite” scalability.
    In the context of his paper distributed transactions do not make sense. That’s clear. Maybe we should be thinking about the benefits of distributed transactions only when scalability and high performance isn’t a major concern.

  4. Eric, my first comment was entirely vague, sorry about that.

    My comment was fishing for any parallels that might exist between WS-TX and some “relaxed consistency” techniques.

    In another of Pat’s posts he refers to a paper called “Isolation Support for Service-based Applications”. This paper describes a technique to use Promises (like a room on the 4th floor) over sets of resources, instead of locks on individual resources (like room 405).

    Some of the compensation capabilities in BPEL allow for things to be cleaned up later, in case of failure. Support for idempotent messages, compensation mechanisms, promises or leases, and so on all seem to provide opportunities for eventually consistent system. I’m trying to learn more about those types of things and suspect that WS-TX has one or two ideas like that.

    Thanks, John.

  5. Hi John,
    Yes, the WS-BusinessActivity spec basically defines a version of the “open nested” transaction protocol, in which nested transactions can commit without the parent committing. If the parent rolls back, the committed subtransactions invoke a compensation action. The user defines the compensation action but WS-BA provides the hook to invoke it on rollback of the parent.
    This is also intended to complement BPEL and was designed, at least in part, with that in mind.

Leave a Reply to John D. Heintz Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s