When Not To Use JTA/XA
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/XA |
JTA/XA benefits |
| At most one resource access |
Safe, although system locks may keep the transaction pending |
Infinite locks are impossible |
| 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 correctness is not guaranteed |
Correct reads in all cases |
| 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 |
