XA transactions or not? Part 2

This is an continuation of an earlier post, as I continue to learn about XA transactions and try to guess if we’ll use ‘em or not.  (I’d just try it out, but I’m not quite there yet, so I’m trying to keep track of what I’m reading as I go along).

Good discussion:

• ActiveMQ JMS FAQ: Should I use XA?
• The API docs for the AbstractMessageListenerContainer, at the top (class-level).  This talks about “custom duplicate message detection” not in an embarrassed way, but presents it as one of the two main alternatives
• setSessionTransacted on the DefaultMessageListenerContainer has this to say:

Setting this flag to “true” will use a short local JMS transaction when running outside of a managed transaction, and a synchronized local JMS transaction in case of a managed transaction (other than an XA transaction) being present. The latter has the effect of a local JMS transaction being managed alongside the main transaction (which might be a native JDBC transaction), with the JMS transaction committing right after the main transaction.

Hmm, a “synchronized local JMS transaction”.  Keith points out, though, that there is a point in time when the database transaction has just been committed but the receiving of the message has not been committed, and if you blow up then, you’re out of sync.  Rats.

But wait, that’s where the custom duplicate message detection comes in.  If you blow up trying to commit the receiving of your JMS message, that means that when you come up again you’ll receive the message again even though you already processed the message before.  This is the scenario where you’d need to be able to detect that you’d already processed this message.

XA resolves the problem a different way, by making sure the duplication never occurs.

Update: Quotes

It’s funny, in the reading I’ve done, what people say about whether to use XA or not.  Here are a few examples:

“Note that XA transaction coordination adds significant runtime overhead, so it might be feasible to avoid it unless absolutely necessary.” –AbstractMessageListenerContainer javadoc

“If you are using more than one resource; e.g. reading a JMS message and writing to a database, you really should use XA…The problem with XA is it can be a bit slow…This adds significant cost (in terms of latency, performance, resources and complexity)…So a good optimisation is to use regular JMS transactions – with no XA…” –ActiveMQ JMS FAQ: Should I use XA?

Increasingly, people want to hit multiple resources simultaneously – their ERP system, their RDBMS, and maybe publish a few messages or throw something on a JMS queue while they’re at it – and they want to do this in a transactionally sound manner. And the way to do this is with XA. And along the way, many developers are finding out about the pitfalls of XA along with the positives, and are also discovering an old adage coming alive once again: “Yep, XA sucks, but for us it sucks less than the alternatives”…And even when all the vendors get it right, I think this article has shown that error recovery in XA can be an arduous task – and harrowing for the operations people to boot. But don’t dismiss XA outright – for all the faults, the benefits are quite real. But it pays to know what you’re really buying into, and hopefully this article has brought a few people a small step closer to what’s really going on under the hood, and how it can affect them. –Mike Spille

About these ads