21

I was confused by the fact that we can allow to use JTA transactions with a non-XA-datasource. Link to the documentation. So what is the difference between XA/non-XA datasources? Why should we use XA-datasources at all?

assylias
  • 321,522
  • 82
  • 660
  • 783
user3663882
  • 6,957
  • 10
  • 51
  • 92

2 Answers2

37

An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources. A non-XA transaction always involves just one resource.

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction. Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).

Note: The explanation above was taken from: theserverside (Mike Spille)

jta="true", Transaction commit automatically.

woodz
  • 737
  • 6
  • 13
ashokhein
  • 1,048
  • 12
  • 38
16

I was wondering about this myself ("use JTA" option in a non-XA Datasource) so I tested several configurations. I have a distributed transaction connecting to two MySQL servers.

Here are my results. If I have:

  1. Two non-XA datasources, both have JTA="true"

Result: Error "Could not enlist in transaction on entering meta-aware object."

  1. Two non-XA datasources, with one JTA="true"

Result: They won't participate in the distributed transaction. Each will commit separately.

  1. One XA and one non-XA with JTA="false",

Result: same as #2

  1. One XA and one non-XA with JTA="true".

Result: Works!

From these, it looks like "use JTA" option indicates if it will participate in a distributed transaction if there's an XA datasource.

jersey-city-ninja
  • 1,038
  • 11
  • 23