Configuring transaction in JBoss

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.

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 Transaction Manager 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.

Frequently asked Jboss Interview Questions

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.

The core and recovery environment can be customized by changing their socket-binding properties, which are referenced in the socket-binding-group configuration section. You might find it more useful to define custom properties in the coordinator-environment section, which might include the default-timeout and logging statistics. Here’s a sample custom transaction configuration:

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.

How does the transaction timeout impact your applications?

The transaction timeout defines the timeout for all JTA transaction enlisted and thus severely affects your application behavior. 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.