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 across all databases/services or all roll back if an error occurs.

The XA standard from the X/Open group and the Java JTA seem to solve exactly this problem using a two-phase commit process. Some databases (mySQL, Postgres, Oracle) support these interfaces, but I get the feeling that they are not often used or declining in popularity. Is that true? And If so, why?

I know there were some replication-related issues with XA on mySQL. Also, XA transactions can be significantly slower. Are there any other reasons why XA is unpopular / uncommon?

Brassware

XA only works well where all (or all but one) of the data sources supports two-phase commit. 2PC has some overhead and requires a bit more monitoring to make sure that abandoned prepared commits don't stick around and clog up the database(s). It's very useful when you need transactional behavior across multiple systems, but best avoided to reduce complexity if you don't. – Hayfork

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.

Recitativo

Actually the second point is not correct. If you use two Oracle databases and make changes to two Oracle databases no XA is required. – Soloman

@Steve: I' confused: The second point is about hype and marketing. But the second half of your comments better matches the first point about "no accepted alternative". I did not say, that there are no alternatives on earth, only none which most other DBs also support. Additionally: One key point of XA is, that there is no "master" DB but only equal players on the field plus one referee (TX manager). With DB-Link all participants have to agree on one "master" DB which has the links set up and is hence a single point of failure. So this is not really "distributed" in my opinion. – Recitativo

You are amking an assumption which is simply wrong distributed transaction does NOT equal the use of XA. – Soloman

@Steve: You are right, for homogeneous systems there are vendor-specific solutions as well. But for heterogeneous systems I'm not aware of any other technology which fits the bill in practice. Do you? – Recitativo

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.

Dissected

>then it should not be used. - Implementations can auto optimize and detect if no transactional work at all was done or the transactional work involved at most 1 local transaction. See e.g. access.redhat.com/site/documentation/en-US/… – Ageratum