Limitations while working with JMS Local Transactions

Several sessions within a single JMS Local Transaction group

Consider several JMS activities present within the same JMS Local Transactional group, but referring to different sessions. These activities may refer to

different Shared JMS Connection resources

Although two Shared JMS Connection resources are exactly identical, but the name of the Event Source may differ. In such cases, they will not be a part of the same JMS Local Transaction

different messaging domains such as Queues and Topics.

The JMS Local Transaction does not span across sessions. Each session is transacted individually and each session is individually committed in a single phase. However, when a failure occurs while committing a particular session, BusinessWorks stops the execution of the process with an exception and no attempt is made to rollback other sessions.

JMS 1.1 not supported

The JMS specification version 1.0.2b specifies that the messaging domains for Point-to-Point and Publish-Subscribe are handled by separate set of interfaces with no common base interface. Since ActiveMatrix BusinessWorks is compliant with this JMS Specification version, it is implied that Topic and Queue sessions cannot share the same JMS session, although they may be required to transact in a single session context. The Sessions created in JMS Local Transactions can be either QueueSessions or TopicSessions, but cannot be both. Thus places a limit on the activities that can participate in a single transacted session.

When activities using both Queue and Topic are in the same transaction group, it results in two separate transactions running independently. However, if one the transaction fails, it is difficult to predict the behavior of the other.

Potential deadlock in Request-Reply activity

Including Request-Reply activities in a transaction may result in a dead-lock situation when the Request and Reply happen on the same queue, and the Reply is bound to the message sent by the request.

Similarly, including JMS Sender and Get JMS Queue Message activities in the same transacted session with the same destination may result in a dead-lock.

Hence to avoid these potential deadlock situations, Request-Reply activities are not included in transactions.

Nested Transactions

Although it is technically possible to nest transaction groups, ActiveMatrix BusinessWorks does not support nesting transactions. Each group starts a separate transaction, irrespective of whether the group is nested or not. Transaction commits and rollbacks are always local to the nested group and are not affected by the outcome of the nesting group.