Chapter 1. Transactions in JBoss EAP

A transaction consists of two or more operations that must either all succeed or all fail. A successful outcome results in a commit, and a failed outcome results in a rollback. In a rollback, each member’s state is reverted before the transaction attempts the commit.

1.1. Transaction Subsystem

The transactions subsystem allows you to configure the Transaction Manager (TM) options, such as timeout values, transaction logging, statistics collection, and whether to use Jakarta Transactions. The transactions subsystem consists of four main elements:

Core environment
The core environment includes the TM interface that allows the JBoss EAP server to control transaction boundaries on behalf of the resource being managed. A transaction coordinator manages communication with the transactional objects and resources that participate in transactions.
Recovery environment
The recovery environment of the JBoss EAP transaction service ensures that the system applies the results of a transaction consistently to all the resources affected by the transaction. This operation continues even if any application process or the machine hosting them crashes or loses network connectivity.
Coordinator environment
The coordinator environment defines custom properties for the transaction, such as default timeout and logging statistics.
Object store
JBoss EAP transaction service uses an object store to record the outcomes of transactions in a persistent manner for failure recovery. The Recovery Manager scans the object store and other locations of information, for transactions and resources that might need recovery.

1.2. Properties of the Transaction

The typical standard for a well-designed transaction is that it is atomic, consistent, isolated, and durable (ACID):

All members of the transaction must make the same decision regarding committing or rolling back the transaction.
Transactions produce consistent results and preserve application specific invariants.
The data being operated on must be locked before modification to prevent processes outside the scope of the transaction from modifying the data.
The effects of a committed transaction are not lost, except in the event of a catastrophic failure.

1.3. Components of a Transaction

Transaction Coordinator
The coordinator governs the outcome of a transaction. It is responsible for ensuring that the web services invoked by the client arrive at a consistent outcome.
Transaction Context
Transaction context is the information about a transaction that is propagated, which allows the transaction to span multiple services.
Transaction Participant
Participants are the services enrolled in a transaction using a participant model.
Transaction Service
Transaction service captures the model of the underlying transaction protocol and coordinates with the participants affiliated with a transaction according to that model.
Transaction API
Transaction API provides an interface for transaction demarcation and the registration of participants.

1.4. Principles of Transaction Management

1.4.1. XA Versus Non-XA Transactions

Non-XA transactions involve only one resource. They do not have a transaction coordinator and a single resource does all the transaction work. They are sometimes called local transactions.

XA transactions involve multiple resources. They also have a coordinating transaction manager with one or more databases, or other resources like Jakarta Messaging, all participating in a single transaction. They are referred to as global transactions.