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):
- Atomic
- All members of the transaction must make the same decision regarding committing or rolling back the transaction.
- Consistent
- Transactions produce consistent results and preserve application specific invariants.
- Isolation
- The data being operated on must be locked before modification to prevent processes outside the scope of the transaction from modifying the data.
- Durable
- 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.
