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 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
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
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