Transactional messaging approaches

JMS services support various approaches to the processing of translational messages. Transactional messaging applies to TIBCO EMS and WebSphere® JMS handlers.

Note: Integration with TIBCO EMS requires the TIBCO EMS feature.
JMS services support the following transactional messaging approaches.

Single JMS session to receive and send

The following conditions apply to the same transacted JMS session to receive a JMS request on the front end and to send it on the back end.
  • Configure the server with the Transactional property enabled.
  • Configure the service with a handler and a URL.
  • For the handler and URL, use the same server configuration with the Transactional property enabled.
  • Define the URL with the Transactional=true parameter.

With this configuration, the handler and URL use the same JMS transacted session. A single COMMIT or ROLLBACK operation is run depending on the processing result to ensure once-and-only-once message delivery of JMS messages.

Single JMS session with commit

The following conditions apply to a COMMIT operation after a successful send on the back end.
  • Configure the server with the Transactional property enabled.
  • Configure the service with a handler and a URL.
  • For the handler and URL, use the same server configuration with the Transactional property enabled.
  • Define the URL with the Sync=true parameter.
This configuration uses one transacted session for these operations.
  1. Receive messages on the front end.
  2. Send messages on the back end.
  3. Issue a COMMIT or ROLLBACK operation immediately after the request message is sent on the back end.
When the handler is configured with a put queue property, the reply message from the back-end response queue is received as a part of a new transaction. In other words, two JMS unidirectional transactions.
  1. The first transaction carries the message from the front-end request queue to the back-end request queue.
  2. The second transaction carries the reply message from back-end response queue for front-end response queue.

Shared JMS session in message fanout

The following requirements apply to receive a JMS request and send it with a results action, dp:url-open, or dp:soap-call extension function with the same transacted JMS session. The results action, dp:url-open, or dp:soap-call extension function might be a part of a request, a response, or an error rule.
  • Configure the server with the Transactional property enabled.
  • Configure the service with a handler.
  • Configure a processing policy with at least one action that uses a URL call such as a results action, a dp:url-open, or dp:soap-call extension function.
    Note: Asynchronous actions do not support the JMS transacted session.
  • Configure all URL open calls with the Transactional=true parameter.
  • Configure the handler and all URL calls with the same server configuration with the Transactional property enabled.
  • If necessary, use a URL defined with the Transactional=true parameter.

In this configuration, the same transacted JMS session receives the message, sends it with a results action or a dp:url-open extension function, and can send on the URL. The JMS transacted session is shared not only between the handler and the URL, but also between any URL calls in the processing policy.

A single COMMIT or ROLLBACK operation is run depending on processing result to ensure once-and-only-once message delivery to the JMS messages. All calls to the server use the same shared, transacted session.

Shared JMS session in message fanout with commit

The following requirements apply to run a COMMIT operation on the successful send operation on any results action, dp:url-open, or dp:soap-call extension functions. The results action, dp:url-open, or dp:soap-call extension function might be a part of either a request, a response, or an error rule.
  • Configure the server with the Transactional property enabled.
  • Configure the service with a handler.
  • Configure a processing policy with at least one action that uses a URL call such as a results action, a dp:url-open, or dp:soap-call extension function.
    Note: Asynchronous actions do not support the JMS transacted session.
  • Specify the Sync=true parameter on the URL open calls where COMMIT or ROLLBACK is done immediately after the message is sent.
  • Configure the handler and all URL calls with the same server configuration with the Transactional property enabled.
  • If necessary, use a URL.
In this configuration, the same transacted JMS session processing occurs.
  1. Receives the message on the front end.
  2. Sends the message with a processing action
  3. Immediately runs a COMMIT or ROLLBACK operation.

The COMMIT or ROLLBACK operation can be run on any results action, dp:url-open, or dp:soap-call extension function that is part of the processing policy after the request message was sent to the server. If the JMS session is shared between the front end and the back end, this COMMIT or ROLLBACK serves as the end of transactions for both receive and send operation.

Under the following conditions, a new transaction is created. This new transaction is committed or rolled back when the processing policy finishes or when some other action is configured with a URL call with the Sync=true parameter.
  • The URL is defined with a reply queue parameter.
  • The processing policy contains any other actions with the same shared transacted JMS session.