Demystifying Datasource JTA and XA settings on JBoss-WildFly

One topic which is often misunderstood by middleware administrators is the configuration of JTA and XA attributes and their effect on transactions. Let’s see more in practice.

Basically on a JBoss AS 6/WildFly configuration you can choose three different strategies as far as transactioons are concerned:

1) Setting jta = false and Non-XA datasource

 <datasource jta="false"  . . . >

When setting this option you will be responsible for managing by yourself the transactions.  For example, the following code will work when using a Datasource with JTA=false:

@Resource(mappedName="java:jboss/datasources/ExampleDS")  
private DataSource ds;  
. . . . . . . . . . .
Connection conn = ds.getConnection();
conn.setAutoCommit(false);

PreparedStatement stmt = conn.prepareStatement("INSERT into PROPERTY values (?,?)");
stmt.setString(1,key);
stmt.setString(2,value);
stmt.execute();

conn.commit();

In practice, when you use the datasource with jta=false in a method of a transactional component (like an EJB), the datasource will not be enlisted in global transaction. That means all data changes are committed immediately. Although you can manually commit the datasource transaction by setting autocommit to false.

On the other hand, if your datasource has jta=true then the datasource is enlisted to the global transaction and the commit on data changes is governed by the TransactionManager (for example, at the end of the EJB CMT method).

Please note: the datasource with jta=false corresponds exactly to the older definition of local-tx-datasource you can find in JBoss AS 4/5

What if you are using JPA instead ?

So, when using plain JDBC you can handle by yourself transaction boundaries using commit/rollback. What about if you are using JPA with JTA=false? in short, the transaction-type for JPA will be RESOURCE_LOCAL. This would use basic JDBC-level transactions. In such scenario you are responsible for EntityManager (PersistenceContext/Cache) creating and tracking and you have to follow these rules:

  • You must use the EntityManagerFactory to get an EntityManager
  • The resulting EntityManager instance is a PersistenceContext/Cache An EntityManagerFactory can be injected via the @PersistenceUnit annotation only (not @PersistenceContext)
  • You are not allowed to use @PersistenceContext to refer to a unit of type RESOURCE_LOCAL
  • You must use the EntityTransaction API to begin/commit around every call to your EntityManger

Here is an example of using JPA with a RESOURCE_LOCAL transaction:

@PersistenceUnit(unitName="unit01")
private EntityManagerFactory emf;
	
EntityManager em = emf.createEntityManager();
em.getTransaction().begin();
em.persist(mag);
em.getTransaction().commit();

 2) Setting jta = true and Non-XA datasource

 <datasource jta="true"  . . . >

This is the default. When JTA is true, the JCA connection pool manager knows to enlist the connection into the JTA transaction. This means that, if the Driver and the database support it, you can use JTA transaction for a single resource.

@PersistenceContext(unitName = "unit01")
private EntityManager entityManager;

public void addMovie(Movie movie) throws Exception {
        entityManager.persist(movie);
}

If you try to manage JDBC transactions by yourself when jta=true an exception will be raised:

12:11:17,145 SEVERE [com.sample.Bean] (http-/127.0.0.1:8080-1) null: java.sql.SQLException: You cannot set autocommit during a managed transaction!
	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.setJdbcAutoCommit(BaseWrapperManagedConnection.java:961)
	at org.jboss.jca.adapters.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:716)

 3) Using an XA datasource

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. 

 <xa-datasource . . . .>

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.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources. 

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource can’t participate in a global transaction 

Found the article helpful? if so please follow us on Socials