What jta setting should be used when defining a datasource in JBoss

Environment

• Red Hat JBoss Enterprise Application Platform (EAP)
  • 6
  • 7
• Java Connector Architecture (JCA)
• jta per:
  • jboss-as-datasources_1_0.xsd
  • jboss-as-datasources_1_1.xsd
  • jboss-as-datasources_1_2.xsd
• can be seen in stacktrace (NoTxConnectionListener is the key part) when jta=false is used
  • org.jboss.jca.core.connectionmanager.listener.NoTxConnectionListener.connectionClosed

Issue

• What is the default jta value?
• When should jta be set to false?

Resolution

The default value of jta is true ¹.

jta=true indicates that the datasource will honor the Java Transaction API and allows better tracking of connections by the JCA implementation.

The jta setting should only be changed from true for specific use cases

• Setting jta=false is necessary for legacy application code which is incompatible with JTA. Such code can usually be identified by its explicit calls to Content from docs.oracle.com is not included.Connection.setAutoCommit(boolean) or Content from docs.oracle.com is not included.Connection.commit() / Content from docs.oracle.com is not included.Connection.rollback().
• Setting jta=false for a data source pool of JDBC connections prevents the connections from being enlisted in a transaction. This can be perceived as a performance benefit though it will limit the use of the connections from the pool as detailed below.

Since non-JTA connections cannot participate in a JTA transaction, when such connections are used in the context of JTA transactions their use should be limited to read-only operations. Setting jta=false for data sources from which connections are used in write operations may result in data inconsistency. Non-JTA connections are left in auto-commit mode regardless of any existing JTA transaction context. Each statement executed (SQL INSERT, UPDATE or DELETE) on such connections is implicitly committed, immediately. In a case where an EJB obtains a connection in the context of a JTA transaction (whether in a CMT REQUIRED method scope or after UserTransaction.begin()) and executes multiple writes, transactional integrity cannot be guaranteed by JBoss. If one or more updates succeed followed by a failure, the work performed by the "transactional" method will be non-atomic (i.e. some updates will have been committed while others have not). Application code becomes responsible for preserving data integrity in such cases. Note that writes using both JTA and non-JTA connections within a transaction are unsafe even if the application code manages the transaction context because commit cannot be performed atomically.

Note that leak detection tooling differs depending on the jta setting:

• JTA datasources can leverage either the cached connection manager debug facility or the leak dumper pool (available only in EAP 6.4 and later releases).
• Non-JTA datasources cannot use the cached connection manager debug facility.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.