CODEWITHSUNDEEP
mysqlpostgresqljtadistributed-transactionsxa
Chris Sears
Chris Sears

Reputation: 6802

Are XA/JTA transactions still used?

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?

Upvotes: 6

Views: 4292

Answers (2)

A.H.
A.H.

Reputation: 66263

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.

Upvotes: 9

aerobiotic
aerobiotic

Reputation: 381

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.

Upvotes: 1

Related Questions