One of the most important functional aspects supported by the service pipeline is that of the transactional execution of the pipeline, in other words the ability to execute all of the actions and message deliveries within a single, consistent context.
Transactional behavior is usually defined using the acronym ACID:
- Atomicity: A transactional context is atomic, which means that every transactional resource within the context will be updated if the transaction is successful. If the transaction is unsuccessful then the transactional resources will remain unchanged.
- Consistency: If the transaction is successful then each transactional resource will move from one consistent state to another.
- Isolation: Each transactional context is isolated from any other transactional context. Any modifications to a transactional resource will not be visible to other contexts until the transaction has successfully committed.
- Durability: A successful transaction will result in the transactional resources persisting their state in such a way that they can be recovered, should anything go wrong.
JBoss ESB supports three transactional transports, JMS, SQL, and InVM, with both the JMS and SQL transports supporting full ACID properties. The InVM transport relaxes the ACID properties and does not support durability, its message queue is maintained in volatile memory and will be lost should the ESB server terminate.
When a message is delivered to the service pipeline, using one of the transports that supports transactional delivery, it is possible to execute all of the actions in the pipeline within a transactional context. Each transactional resource accessed within the actions will be enlisted as part of the transaction, allowing the transaction manager to control the consistent outcome of the pipeline execution.
Note
When using a transactional transport to deliver messages it is important to understand when the messages will be sent. Each message sent using a transactional transport will be associated with the encompassing transaction and will only be sent once the transaction commits. The consequence of this is that sending a message to a service, then waiting for the response within the same transaction, will not work.
If the framework detects an attempt to execute a synchronous invocation, while in a transactional context, then it will raise an IncompatibleTransactionScopeException exception.
One way to handle this requirement is to split the processing of the pipeline into two sections, each with their own transactional context. See Continuations for more information on this topology.