Copyright © Cloud Software Group, Inc. All Rights Reserved

JMS Local Transaction

The JMS Local transaction allows JMS activities to participate in a transaction.

The JMS specification defines the concept of a transacted JMS Session that can be used to transact sends and receives, all or none of which will get executed when the session is committed.

A session, when specified as transacted, supports a single series of transactions. Each transaction groups a set of produced messages and a set of consumed messages into an atomic unit of work. Multiple transactions organize the session’s input message stream and output message stream into a series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and the associated unit of 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.

The JMS Local transaction type allows JMS sender activities - JMS Queue Sender and JMS Topic Publisher, Get JMS Queue Message activity, JMS Event Sources - JMS Queue Receiver and JMS Topic Subscriber, and Reply To JMS Message activities to participate in the transaction. At runtime, the underlying JMS activities use the same transacted JMS session to provide transaction semantics for messages sent and received by the JMS activities.

The ActiveEnterprise Adapter activities such as Publisher to Adapter, Adapter Subscriber and Adapter Request-Response Server can also participate in JMS Local transactions.

The JMS Requestors and Wait for JMS Queue/Topic Message activities will not participate in a local transaction even if they are included in a JMS Local transaction group.

The sessions participating in the JMS local transactions cannot process other messages outside the transaction. Since sessions are limited resources defined by the Max Sessions property, the number of messages that can be processed simultaneously, and hence the throughput, can be affected.

Configuring JMS Local Transactions

To configure a JMS Local transaction, select JMS Local Transaction as the transaction type of the group.

To include the JMS Receiver in JMS Local Transaction, choose the Event Source in Include In Transaction.

To exclude a JMS Send activity from a transaction, check the Override Transaction Behavior in the advanced tab.

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 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, 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.

Copyright © Cloud Software Group, Inc. All Rights Reserved