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