Local Transaction

Use Local Transaction group for multiple activities to be part of a local transaction. A local transaction group ensures that all participants of the transaction are rolled back together. A single resource performs all its transaction work.

General

Not all TIBCO ActiveMatrix BusinessWorks™ activities can participate in the local transaction. The following core activity types have local transactional capabilities:

  • JMS
  • JDBC

A Local Transaction group has to be further configured as a specific type of a Local Transaction or Transaction Transport. The Transaction Transport type determines the activities that can participate in this local transaction group. For example, "JDBC" transaction transport only provides transaction support for certain JDBC activities.

If a Call Process activity is used within the local transaction group, then the direct subprocesses called are also part of the local transaction.

For more information about Call Process activity, see Call Process.

The General tab has the following fields.

Name Description
Name The name to be displayed as the label for the activity in the process.
Transaction Transport The transport type. Select from the following available transaction transport types:
  • None
  • JMS: To configure a JMS local transaction, select JMS as the transaction type of the group.
  • JDBC: To configure a JDBC transaction, select JDBC as the transaction type of the group.

JMS

JMS activities participate in a transaction using the JMS local transaction. A JMS session, when specified as transacted, supports a single series of JMS operations. The local transaction group enlists a set of produced messages and a set of consumed messages into a unit of work. JMS local transactions use the underlying JMS sessions to group together all the activities that are part of the transaction group into one unit of work.

All activities using the same JMS connection are part of one transaction. If a transaction group contains activities that use more than one JMS connection, for example, a JMS Send Message activity using connection 1 and another JMS Send Message activity using connection 2, there are two underlying transactions created.

Furthermore, activities must use the same messaging styles to be in the same transaction.

Possible deadlock situation: A deadlock situation arises if you have JMS Send Message and Get JMS Queue Message activities performing JMS operations on the same queue. A message not sent out until a commit is performed, keeps Get JMS Queue Message activity waiting indefinitely.

Important: It is recommended not to have a design that sends and receives messages on the same destination using the same session in a single transaction.

When a transaction commits, its input is acknowledged and the associated output is sent. When a transaction rollback is done, all the produced messages (output stream) are destroyed and the consumed messages (input stream) are automatically recovered. You can use the JMS sender activities with the JMS local transaction. At run time, the underlying JMS activities use the same transacted JMS session to provide transaction semantics for messages sent and received by the JMS activities.

For more information about JMS palette and activities, see JMS Palette.

JDBC

Using the JDBC transaction and multiple JDBC activities, you can access the same database connection to participate in a transaction. Only JDBC activities that use the same JDBC Connection participate in this transaction type. However, other activities can be part of the transaction group. If the transaction commits, all JDBC activities using the same JDBC connection in the transaction group commit. If the transaction rolls back, all JDBC activities using the same JDBC connection in the transaction group roll back.

The transaction group commits automatically, if all activities in the group complete the transaction and a non-error transition is taken out of the transaction group. If any error occurs while processing the activities in the group, including errors in non-JDBC activities, it rolls back the transaction and returns an error. Individual JDBC activities can override the default transaction behavior and commit separately.

For more information about JDBC palette and activities, see JDBC Palette.