When you are using JMS transport for inbound requests, the only way to absolutely guarantee an

exactly once

message delivery is to use a Distributed (XA) transaction surrounding commits of process state to the Process Server database and the read of the JMS message from the queue. Without an XA transaction, it is possible, although extremely rare, to receive a duplicate request if the server goes down at the precise moment when the inbound receive was committed to the Process Server database, but the JMS transaction has not been committed. In this case, the message remains on the queue and may be retried, resulting in a duplicate process request.

You can enable Distributed (XA) Transaction handling for a JMS Messaging Service if your processes require it. Enabling this feature requires several manual steps, outlined below in Required Setup.

Note

: XA transactions can be relatively expensive, so you may see an adverse affect on performance if you choose to enable them.

Using distributed transactions, Process Server can retrieve a message from a message queue and update the database in a single transactional unit adhering to the ACID (Atomicity, Consistency, Isolation and Durability) criteria. This feature guarantees that messages processed from JMS are processed once and only once.

Supported Platforms

XA Transaction processing is supported on all Process Server application servers that include a JTA transaction manager. Te only one that does not is Apache Tomcat.

All Process Server databases (MySQL, DB2, Oracle, and SQLServer) are supported.

Note

: Some databases do not enable XA support by default, and this support needs to be enabled by a database administrator. Consult your database documentation to determine if and how XA transactions are enabled.

Required Setup

Follow these guidelines to set up XA transactions: