Configuring Transactions (JTA) using JBoss / Wildfly

This tutorial discusses about configuring and monitoring transactions using the Java Transaction API(JTA) on Wildfly application server.

Let’s start from some definitions: A transaction can be defined as a group of operations that must be performed as a unit and can involve persisting data objects, sending a message, and so on.
When the operations in a transaction are performed across databases or other resources that reside on separate computers or processes, this is known as a distributed transaction. Such enterprise-wide transactions require special coordination between the resources involved and can be extremely difficult to program reliably. This is where Java Transaction API(JTA)comes in, providing the interface that resources can implement and to which they can bind, in order to participate in a distributed transaction.

For example, the EJB container is a transaction manager that supports JTA and so can participate in distributed transactions involving other EJB containers, as well as third-party JTA resources, such as many database management systems. Within JBoss AS 7 transactions are configured in their own subsystem. The transactions subsystem consists mainly of four elements:
•     Core environment
•     Recovery-environment
•     Coordinator-environment
•     Object-store
The core environment includes the TransactionManager interface, which allows the application server to control the transaction boundaries on behalf of the resource being managed.
A transaction coordinator, in turn, manages communication with transactional objects and resources that participate in transactions.
The recovery subsystem of JBossTS ensures that results of a transaction are applied consistently to all resources affected by the transaction, even if any of the application processes or the machine hosting them crashes or loses network connectivity.
Within the transaction service, JBoss transaction service uses an ObjectStore to persistently record the outcomes of transactions, for failure recovery. As a matter of fact, the RecoveryManager scans the ObjectStore and other locations of information, looking for transactions and resources that require, or may require, recovery.
Here’s a sample custom transaction configuration:

<subsystem xmlns="urn:jboss:domain:transactions:1.3">
            <recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/>
            <coordinator-environment default-timeout="300"/>

The key parameter here, default-timeout, specifies the default transaction timeout to be used for new transactions, which is specified as an integer in seconds.
enable-statistics determines whether or not the transaction service should gather statistical information. The default is to not gather this information.

Since WildFly 23 it is possible to specify the maximum-timeout attribute which comes into play if you set a default-timeout of “0“. If the default timeout is zero then this value is consulted to set the maximum timeout (in seconds) for a transaction managed by the transaction manager. 

A typical JTA transaction might be started by your EJBs or by a JMS Session. So, if the duration of these transactions exceeds the specified timeout setting, the transaction service will roll-back the transactions automatically.
You can modify the default transaction timeout either at application server level by issuing from the CLI:


Or you can specify this annotation at class/method level of your transactional components (i.e. EJBs)
The TransactionTimeout annotation is used to specify the transaction timeout for a given method.

For example:

@TransactionTimeout(value = 10, unit = TimeUnit.SECONDS)

As an alternative you can specify the transaction timeout in the Deployment Descriptor of your jboss-ejb3.xml as follows:

<jboss:ejb-jar xmlns:jboss=""

The maximum timeout, on the other hand, can be set from the CLI as follows:


Once configured your transaction timeout you need to check that JTA statistics are enabled. The default is false, in order to enable it you can issue:


Now, you can monitor your transaction statistics either from the CLI by issuing:


Or using the Admin Console, by selecting the Runtime upper tab and the Subsystems->Transactions view

jta transactions jboss wildfly tutorial jta

Node identifier property is set to the default value. Please make sure it is unique.

When using XA Transaction, the Transaction Manager requires that you set an unique node-identifier in order to be able to recover an XA transaction properly.

If you don’t set it, the following WARN will be displayed:

WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.

If XA transactions are not used, this WARN is harmless.

You can set the node identifier as follows. Define a System Property:


Then use this system property to set the transactions subsystem’s node-identifier attribute:


That results in the following configuration:

<subsystem xmlns="urn:jboss:domain:transactions:6.0">
    <core-environment node-identifier="${}">

Using a System Property to decouple the assignment of the node-identifier is especially useful in domain mode, where you can have multiple servers on the same configuration:


Now it’s sufficient to set the single property for the profile we’re working with: