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:

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


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s