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?

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.