When Not To Use JTA/XA

02 Aug 2015 - 06:02 | Version 11 | | ,
The table below shows some cases where you can consider not using JTA/XA, and some trade-offs. In all other cases, JTA/XA offers significant benefits in terms of reliability and simplicity.

ScenarioSorted ascending Feasibility without JTA/XA JTA/XA benefits
At most one resource access Safe, although system locks may keep the transaction pending Infinite locks are impossible because XA propagates transaction timeouts to the resource
Many back-ends Not safe: only do this if you are willing to face data loss in case of a crash No data loss or corruption
Multiple resource accesses, but in same back-end system Safe if you use the same connection for each access - sharing data between different accesses may require thread-local manipulation of the shared connection handle, and commit handling is complex Data sharing is handled by XA
Multiple queries in different back-end systems Possible, though global correctness is not guaranteed because there is no global transaction concept: your transaction may be reading values that never existed in that combination Correct reads in all cases because locks will be kept for the global transaction - avoiding interleaving effects with other, concurrent transactions

Contact Us

Atomikos Corporate Headquarters
Hoveniersstraat, 39/1, 2800
Mechelen, Belgium

E info@atomikos.com
E sales@atomikos.com
T +3215613055

Subscribe to our newsletter

Never miss an update

Copyright 2015 Atomikos BVBA