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.

Scenario Feasibility without JTA/XASorted ascending JTA/XA benefits
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 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
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
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

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