Native transactions

It was interesting reading The Power of Native Transactions presentation, which could probably be subtitled: When You Don't Own a Transaction Manager, What Do You Do? Actually I don't mean to pick on Spring as this is a problem we used to come across many times when an independent TM vendor. Typically we'd hear "Aren't the transactions in my database good enough?", "Why do I need recovery?" and that old one but good one "I'm not interested in distributed transactions so I don't need two-phase commit."

I've said enough times that traditional transactions (aka ACID) aren't suitable for every occasion. The fact they have been shoehorned into situations where they aren't needed or aren't applicable has hurt the industry as well as disillusioned some people. Probably as a result, as we saw throughout the BTP effort people equate two-phase commit with ACID semantics, which is clearly wrong. Or that the two phases have to somehow be tied in with prepare/commit/rollback, which as BTP (and others) showed is again wrong.

At some point I need to finish my paper on consensus in distributed systems, because it's fairly obvious that some people who see transactions (and specifically 2PC) as "evil" and something that can be "programmed around" don't fully understand what's happening under the covers of any good transaction manager. Yes it's possible that some uses of transactions can be redesigned without them, but that doesn't mean they all can be.

Anyway, back to the topic at hand. I read the presentation with interest because it's always good to hear experiences from using transaction systems. What follows is almost a review of the presentation as if I had to review it for inclusion (or not) in a conference. I blame the fact that I sit on so many program committees and review a lot of papers each year: it alters your mindset a bit.

First I agree with one of the core messages in the Spring paper: that sometimes you don't need transactions at all and that one-size doesn't fit all. But sometimes you do need a good transaction manager and you need to understand when and why.

It would have been good to see a discussion of local and global transactions, but then I suppose the point of the talk is to emphasize the use of local transactions (through a native transaction manager). What I find frustrating is that yet again someone equates JDBC save points with nested transactions. Yes you can map a save point to a transaction boundary, but you that doesn't give you nested commit semantics or concurrency control, for instance. If you're going to talk about nested transactions, please stick with the standard definition. Even OTS managed to do that, despite breaking the model in other ways.

I know (hope) that the JBossTS team are going to say a thing or two about the common misunderstandings and misconceptions around XA, so I'll try not to steal their thunder. But I do need to point out that the read-only flag is neither a Spring invention nor something only found in specific databases: it's a core part of two-phase commit (through the read-only vote that can be returned during prepare). So JTA does support it. Of course how the resource manager figures out how to return read-only is something that the transaction manager doesn't mandate (and it shouldn't). So in that regard an annotation makes sense. But other approaches are possible (e.g., making locking rules explicit within the business object.)

The presentation also gives us the notion that 2PC is for distributed transactions only. No! As I said above, 2PC is a consensus protocol so it's needed when you have more than one participant, even if they are on the same machine. Unless of course you're not interested in them reaching agreement. So please, don't equate 2PC with distributed transactions: I also know of many distributed systems using transactions where 2PC isn't the norm!

I hate subjective statements like "XA is Non-Trivial to Set Up." Yes, so is the brake system in my car, but I need it nonetheless! So although XA can be a PITA at times, if used correctly (in the right situations) it's well worth paying. Plus it's often a one-off cost that over the lifetime of a deployment fades into insignificance compared to the benefits, or the setup costs of other components. So try to look on this objectively, weighing up the pros and cons (which is maybe what the presentation is trying to say, although perhaps for obvious reasons it seems to push the non-XA approaches more.)

Something else that surprised me about the presentation was the inference that an application that uses an XA transaction manager, or perhaps one that implements 2PC in general, must incur the overhead of a log even if there's a single resource involved in the transaction (something which using "native" transactions would miraculously avoid). So the one-phase commit optimization hasn't been invented? Once again this is something that's part of XA too. Any good transaction manager implementation should take advantage of this and in this situation you wouldn't get a log created! And I'm not even going to bother about other optimizations such as presumed abort.

I suppose this misunderstanding leads to another subjective statement: "Native Transactions - As Efficient As It Gets". Followed by the recommendation that you should try to use multiple (independent) native transactions, with a single resource in each of course. Yes, that's also one of the extended transaction models we documented when developing The Additional Structuring Mechanisms for the OTS. However, as was pointed out back then, you don't get the same semantics (remember what I was saying about consensus?) If you need atomicity then there are very few alternatives outside of magic or quantum mechanics!

In conclusion, I think the presentation wasn't too bad if a little vendor specific (which makes sense given the background and conference). But if you're really interested in transactions, where to use them, where not to use them, and precisely what the trade-offs are in a more objective manner then there's a lot of other good information out there.