Transaction Management

Contents

Approach

The transaction management is done by Fiorano Peer Server using the Component Control Protocol which is in place for communication between components and FPS. The communication happens using two predefined topics with persistent messages. This restricts all the participants in a transaction to run in a single peer server.

All the tasks designated to the component are done at the framework level. So there is not need for a custom component developer to handle/generate the events. Only the appropriate XAResource class has to be plugged in the API provided.

Registration/Enlisting participants

The components participating in a transaction register with Peer server at startup and register a common transaction ID. The transaction identifier will be used by peer server to distinguish between different transactions that might be registered in the same peer server.
Application developer specifies the same transaction identifier for all the participants in particular transaction group. The start and end node in the transaction are also mentioned by the application composer.

Transaction Processing

Once a request that needs to be processed in transactional context is received, the component that is marked as the start of the transaction will generate a message ID for the inbound message. The message ID generated by the component is passed along the transaction chain via a message property.

The message ID thus propagated will be used to prepare/commit/rollback the transaction corresponding to the particular message. Depending on the nature of the resource commit, adapters/components maintain a pool of commit able resources where each resource is allocated per message ID.

Two-Phase Commit

Once the message reaches the end component in the chain, the component sends a commit request event to the peer server which includes details of the transaction ID as well as the message ID which needs to be committed. The Peer server, upon receiving the request, identifies all the components which registered with that particular transaction ID.

A prepare event is sent to all the participants of the transaction with the particular message ID. On receiving the prepare event the components prepare the transactional context pertaining to the messageID and sends the prepare status event to the server.

On receiving prepare status as success from all the participants registered server sends a commit event to the components which makes all the participants commit the transaction. If any of the status event is received as failure or not received within pre defined timeout or if any component sends rollback request event, the server sends a rollback event to all the participants. The components upon commit/rollback send a commit/rollback success/failure status event back to the server which will be used for logging the transactional state.
Upon rollback of a transaction, the input message corresponding to the rolled back message ID is sent to the exception port of the start component, for remedial purposes.

Resources not capable of supporting 2 Phase commit can simply send success event in response to the prepare event and participate in the overall transaction.
The implementation of transaction processing for an XA based resource is implemented in a sample component with details about changes to be done in custom component for the same. This is present at the location %FIORANO_HOME%/esb/tools/templates/samples/TransactionManagement