To XA or not to XA

That should be the ques­tion, but most of the time it is not.

Many peo­ple don't seem to re­al­ize when and why they need JTA/XA trans­ac­tions. I re­al­ly think you should look into this tech­nol­o­gy, be­cause of a num­ber of very good rea­sons. Let this blog post be your guide...

The only case where XA is not use­ful: if you only ac­cess one back-end sys­tem (un­less you need hot back-up and failover!). In all oth­er cas­es XA can help (as­sum­ing that you have XA con­nec­tors, like most ven­dors now of­fer). Note that JMS also counts as a back-end sys­tem ac­cess tech­nol­o­gy! So if you have one data­base and one JMS queue to ac­cess (on be­half of the same user/trans­ac­tion) then you should def­i­nite­ly con­sid­er XA!

The most com­mon ob­jec­tion: "yes, but XA is bad for per­for­mance!". Maybe. Did you try it? If you didn't then you don't know what you are talk­ing about. While it is true that XA in­curs some over­head that you would avoid with­out, this over­head is nec­es­sary to en­sure cor­rect­ness of your trans­ac­tions. The im­pli­ca­tion: with­out XA you can mess up your data re­al­ly fast:-) My ad­vice: try XA first, and only con­sid­er al­ter­na­tives if you re­al­ly re­al­ly re­al­ly re­al­ly have to (or if you don't care about your data). XA will make your code a lot sim­pler and more ro­bust, trust me!

"I can de­sign/code with­out it". Is that so? It is true that one could write soft­ware that does sim­i­lar things as JTA/XA. In the lim­it, you could even end up writ­ing your own trans­ac­tion man­ag­er. But is it with­in the scope of your project? I se­ri­ous­ly doubt it. And is your code go­ing to be bul­let-proof? Maybe, maybe not. Will you test all pos­si­ble anom­alies and crash­es in all pos­si­ble com­bi­na­tions? Not like­ly (as­sum­ing you even know what those anom­alies are - this is not so easy in some cas­es). And: are you go­ing to main­tain the code? Even less like­ly, be­cause in­fra­struc­ture code is of­ten ne­glect­ed. Not to men­tion the col­leagues who will in­her­it your code af­ter you leave to an­oth­er job.

To con­clude, con­sid­er this sce­nario: en­ter­prise XYZ has been cod­ing around XA for years. They now have 23 en­ter­prise projects who all con­tain workaround code to avoid XA. Just cal­cu­late what it takes to main­tain this un­nec­es­sary code in each of these 23 projects, and things may not even work cor­rect­ly! And re­mem­ber: the code you write to­day is the lega­cy of to­mor­row.

Yes, it is true that XA soft­ware used to be ex­pen­sive. To­day, it is no longer the case. For in­stance, you can use Atomikos Trans­ac­tion­sEssen­tials for free...

Still not con­vinced?

Here is my favourite ques­tion: what hap­pens to your data af­ter a crash of your serv­er(s)? If you don't know the an­swer, please use XA. And if you do know the an­swer: are you will­ing to bet on it?

Let us help you for free!

Why not con­sid­er a free tri­al of Ex­tremeTrans­ac­tions? You can ap­ply be­low. Trust us: dur­ing the free tri­al we also give you free sup­port - so we can't af­ford to tell you stuff that does not work (or we'd be fool­ing our­selves with need­less free sup­port work)!

Try Ex­tremeTrans­ac­tions For Free