Configuring XA Transactions

To configure an XA Transaction, select XA Transaction as the transaction type of the group.

JDBC Connections used by JDBC activities in the transaction group must be configured to use XA as the connection type. JMS activities must be configured to use the XA connection factory.

The XA Transaction group has the following fields on the transaction group’s Configuration tab:

Field

Description

Transaction Manager

An XA Transaction shared configuration resource. For more information about this resource, see TIBCO ActiveMatrix BusinessWorks Palette Reference.

Include In Transaction

Certain resources, such as JMS Queue Receiver, Wait for JMS Queue Message, or JMS Topic Subscriber expect acknowledge messages to be sent to the server. Normally, this is done by using a Confirm activity. These resources can also specify an acknowledge mode of "Transactional" that specifies their acknowledgement should be part of a transaction.

This field allows you to specify the resource for which you would like to send an acknowledgement message. This message is part of the transaction, if the transaction completes successfully. There is no need for a Confirm activity for the resources specified in this field.

Note: Transactional acknowledge mode is not supported for Wait for JMS Topic Message activities.

Include Checkpoint

When this field is checked, an implicit checkpoint is performed after the last activity in the group completes successfully and before the transaction is committed. The deployment configuration must specify a database for storing process engine information and the JDBC Connection used must specify XA as the connection type for this checkpoint to participate in the transaction.

Checkpoint Duplicate Key

When the Include Checkpoints field is checked, you can specify a duplicate key in this field to perform duplicate checking. This is useful if the checkpoint included in the transaction is the first checkpoint in the process definition. If the process engine crashes after the checkpoint, restarted process instances can use the duplicate key to determine if the transaction has already occurred. For more information about specifying duplicate keys, see Detecting Duplicate Process Instances.