Are XA/JTA transactions still used?

Question

I have an application that interacts multiple databases and some custom services. For some operations, I need transaction-like behavior where a set of changes either commit acro

Answer 1

There are several point with XA:

• It does its job and there is no accepted alternative. If you must use distributed transactions, then there is no way around XA.
• It is "standard technology", no hype and no marketing. Therefore it flies below the radars of most people.
• Even when it is used, there is a good chance that Jack Application Developer does not know it as most parts are usually hidden in some frameworks.
• The need for XA is indeed somewhat on decline, because Service Oriented Architecture (SOA) and message queuing are hyped architecture paradigms which try to avoid such tight coupling of subsystems. Although at least SOA also seems to be declining quite well. ;-)
• Often forgotten parts of XA are the required code and tools which are used when a transaction actually breaks. There are some outskirts in XA where the Transaction Manager can neither commit nor rollback all resources for quite some time. This point only increases the "use it only if you really must" point.

Answer 2

They are still used for exactly what you have mentioned. If an operation on one of the databases fails then it all gets rolled back.

They are slower, and so if XA is not needed (i.e. it's an autonomous operation or non-transactional), then it should not be used.

The Java EE container may even force you to use an XA datasource when dealing with multiple DBs.