To XA or not to XA
That should be the question, but most of the time it is not.
Many people don't seem to realize when and why they need JTA/XA transactions. I really think you should look into this technology, because of a number of very good reasons. Let this blog post be your guide...
The only case where XA is not useful: if you only access one back-end system. In all other cases XA can help (assuming that you have XA connectors, like most vendors now offer). Note that JMS also counts as a back-end system access technology! So if you have one database and one JMS queue to access (on behalf of the same user/transaction) then you should definitely consider XA!
The most common objection: "yes, but XA is bad for performance!". Maybe. Did you try it? If you didn't then you don't know what you are talking about. While it is true that XA incurs some overhead that you would avoid without, this overhead is necessary to ensure correctness of your transactions. The implication: without XA you can mess up your data really fast:-) My advice: try XA first, and only consider alternatives if you really really really really have to (or if you don't care about your data). XA will make your code a lot simpler and more robust, trust me!
"I can design/code without it". Is that so? It is true that one could write software that does similar things as JTA/XA. In the limit, you could even end up writing your own transaction manager. But is it within the scope of your project? I seriously doubt it. And is your code going to be bullet-proof? Maybe, maybe not. Will you test all possible anomalies and crashes in all possible combinations? Not likely (assuming you even know what those anomalies are - this is not so easy in some cases). And: are you going to maintain the code? Even less likely, because infrastructure code is often neglected. Not to mention the colleagues who will inherit your code after you leave to another job.
To conclude, consider this scenario: enterprise XYZ has been coding around XA for years. They now have 23 enterprise projects who all contain workaround code to avoid XA. Just calculate what it takes to maintain this unnecessary code in each of these 23 projects, and things may not even work correctly! And remember: the code you write today is the legacy of tomorrow.
Yes, it is true that XA software used to be expensive. Today, it is no longer the case. For instance, you can use Atomikos TransactionsEssentials for free...
Still not convinced? Here is my favourite question: what happens to your data after a crash of your server(s)? If you don't know the answer, please use XA. And if you do know the answer: are you willing to bet on it?
Cheers
Many people don't seem to realize when and why they need JTA/XA transactions. I really think you should look into this technology, because of a number of very good reasons. Let this blog post be your guide...
The only case where XA is not useful: if you only access one back-end system. In all other cases XA can help (assuming that you have XA connectors, like most vendors now offer). Note that JMS also counts as a back-end system access technology! So if you have one database and one JMS queue to access (on behalf of the same user/transaction) then you should definitely consider XA!
The most common objection: "yes, but XA is bad for performance!". Maybe. Did you try it? If you didn't then you don't know what you are talking about. While it is true that XA incurs some overhead that you would avoid without, this overhead is necessary to ensure correctness of your transactions. The implication: without XA you can mess up your data really fast:-) My advice: try XA first, and only consider alternatives if you really really really really have to (or if you don't care about your data). XA will make your code a lot simpler and more robust, trust me!
"I can design/code without it". Is that so? It is true that one could write software that does similar things as JTA/XA. In the limit, you could even end up writing your own transaction manager. But is it within the scope of your project? I seriously doubt it. And is your code going to be bullet-proof? Maybe, maybe not. Will you test all possible anomalies and crashes in all possible combinations? Not likely (assuming you even know what those anomalies are - this is not so easy in some cases). And: are you going to maintain the code? Even less likely, because infrastructure code is often neglected. Not to mention the colleagues who will inherit your code after you leave to another job.
To conclude, consider this scenario: enterprise XYZ has been coding around XA for years. They now have 23 enterprise projects who all contain workaround code to avoid XA. Just calculate what it takes to maintain this unnecessary code in each of these 23 projects, and things may not even work correctly! And remember: the code you write today is the legacy of tomorrow.
Yes, it is true that XA software used to be expensive. Today, it is no longer the case. For instance, you can use Atomikos TransactionsEssentials for free...
Still not convinced? Here is my favourite question: what happens to your data after a crash of your server(s)? If you don't know the answer, please use XA. And if you do know the answer: are you willing to bet on it?
Cheers
posted by Guy at 7:32 AM
<< Home