JMS Transacted OneWay

The JMS Transacted OneWay policy applies to SOAP and JMS bindings. It ensures delivery of one-way messages by wrapping message operations (send or receive) within transactions. JMS Transacted OneWay policy is supported only when the configured JMS provider is an Enterprise Message Service.

The JMS service binding starts a transaction by enlisting an incoming JMS message. The transaction context is passed to subsequent components, ensuring that the operations from these components are part of the transaction. The operations include: database operations performed by components such as Java, Spring, Mediation, and BWSE and the outgoing JMS message from the JMS reference binding.

When control returns to the JMS service binding, the transaction is either committed, if the provider returns normally, or it is rolled back, if the provider throws an undeclared fault or exception.

At a JMS service binding, this policy set ensures that the binding receives each inbound one-way message from the JMS destination within a transaction started by the JMS service binding. If the transaction rolls back, the message remains in the original JMS destination, which can be redelivered to the JMS service binding within a subsequent transaction. If redelivery succeeds and control is returned to the JMS binding successfully, the JMS message on the source destination will be committed.

If re-delivery attempts are exhausted, then the message will be moved to the configured error-queue (if it is configured) in the same transaction. If the error-queue is not configured, the message is discarded.

At a JMS reference binding, this policy set ensures that the JMS binding sends each outbound one-way message within the component's open transaction.

This policy set can apply to any JMS binding on a promoted service or reference.
Note:
  • The JMS binding and the components wired to it must be deployed to the single node to achieve a transaction that includes the incoming JMS message, the database operations, and the outgoing JMS message from the JMS binding on the reference side.
  • The components participating in the transaction must be configured with a Managed Global Transaction policy.
  • If an error queue has not been created and the JMS Provider does not support dynamic queue creation or the user of the provider does not have create permissions, JMS binding deployment fails. If the error queue is deleted after the application is deployed, JMS binding attempts to move the erroneous message to the error queue. On failing to do so, it indefinitely attempts to move the message to the error queue regardless of the redelivery attempt configuration.
Parameter Description
Max redelivery count The JMS binding continues to attempt delivery until either delivery succeeds, or the number of delivery attempts reaches this value. This value specifies the total number of times the message is delivered, including the first delivery.
For example:
  • If the value is 1, the Messaging Bus attempts only the initial delivery and then stops.
  • If the value is 3, the sequence is as follows:
    1. The message is delivered once. (first attempt)
    2. On failure, the message is delivered again. (second attempt)
    3. On failure, the message is delivered again. (third attempt)
    4. A failure is reported.

Default: 0.

Redelivery delay interval (s) After each failed delivery attempt, the JMS binding waits for this interval before its next attempt.

Default: 15.

Exceptions upon which to stop redelivery If the provider throws any exception in this list, then the JMS binding cancels further delivery attempts (even if the maximum redelivery count has not yet reached).

Default: None.

Enable error queue Indicate how a message is treated when delivery fails—that is, the JMS binding exceeds the maximum delivery count or the service implementation throws an error that stops delivery.

When checked, place the message on the error queue defined in the Error queue name field. When unchecked, discard the message.

Default: Unchecked.

Transactional

Indicates whether move to error queue should happen in the same session transaction in which message from source destination was received.

Note: Transaction here is not an XA transaction, this is only a session transaction.
Error queue name The queue on which JMS binding places failed message if the error queue is enabled.

A warning is displayed on the Promoted Service indicating configured error queue should be present on the JMS provider.

Default: Default error queue name is JMSAtLeastOnce_ErrorQueue.