When you are using JMS transport for inbound requests, the only way to absolutely guarantee an
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.
: 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.
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.
: 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.
Follow these guidelines to set up XA transactions:
Ensure that your database is configured to support XA transactions.
Create a separate JDBC datasource that supports XA transactions. Consult the documentation for your database and application server for datasource configuration details. By default, Process Server looks for a datasource whose JNDI name is
: Process Server uses a separate datasource configuration for XA transactions since mixing XA and non-XA transactions within the same connection pool can often cause problems.
Set up an XA-aware JMS connection factory that enlists with the JTA transaction manager hosted by the application server. Consult the documentation for your JMS provider for details. Specify this connection factory on the JMS Messaging Service page of the
Application Integration Console
box in the Messaging Service window that appears when you create a new messaging service.