Transacted OneWay Transactions
A Transacted OneWay transaction provides transaction support for component service messages, database operations, and component reference messages. OneWay transactions are supported only for In-Only MEPs.
An In-Only MEP message received by a component service, the database operations performed in the component implementation, and the In-Only message sent by component references can be part of a transaction and is atomically committed or rolled back. The primary application of Transacted OneWay transactions is ensuring that one-way messages are not lost in the course of processing database updates. A Transacted OneWay transaction conforms to the SCA transactedOneWay intent.
Transacted OneWay transactions are enabled by configuring a Transacted OneWay intent and policy on a composite service, component service, component reference, or composite reference that are not simultaneously enabled with any of following intents:
- AtLeastOnce
- AtMostOnce
Scenarios
The following figure illustrates the participants in a OneWay transaction.
The transaction participants are:
- The JMS binding's incoming message (1).
- The component service's incoming message (2).
- The operations on Database 1 (3).
- The component reference's outgoing message (4).
- The JMS binding's outgoing message (5). The message is sent to the referenced service when the transaction is committed.
Runtime Behavior
In-Only messages are exchanged between components via the Messaging Bus even if the components are deployed in the same node.
Component Service Message Processing
If the component service does not have a transaction then:
- The TIBCO ActiveMatrix platform starts a transaction, enlists the request message in the transaction, and delivers the request message to the component implementation.
- If the component implementation successfully processes the request message and does not throw an exception, the transaction is committed.
- If the component
implementation throws an exception, the associated Transacted OneWay policy
configuration dictates the behavior as follows:
- The exception is logged.
- If the exception is
one of the exceptions upon which to stop redelivery as configured in the
Transacted OneWay policy then:
- The transaction is rolled back.
- The message is not redelivered to the component implementation.
- The message is placed in the error queue or discarded based on the corresponding Transacted OneWay Policy configuration.
- Processing of the request message is considered complete.
- If redeliveryCount <= maxRedeliveryCount then the transaction is rolled back and the message is redelivered to the implementation under a new transaction after a delay interval specified in the Transacted OneWay policy.
- If redeliveryCount
> maxRedeliveryCount then:
- The transaction is rolled back.
- The message is not redelivered to the component implementation.
- The message is placed in the error queue or discarded based on the corresponding Transacted OneWay policy configuration.
- Processing of the request message is considered complete.
Component Reference Message Processing
If a transaction is active:
- The request message is enqueued as part of the transaction and placed in the target queue.
- If the request message is placed in the target queue successfully then the control is returned to component implementation without any errors; otherwise an exception is returned to the component implementation.
If a transaction is not active, an exception is returned to the component implementation.