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