Transactions

When using CLIENT_ACKNOWLEDGE mode, messages are consumed in a transaction, and sent without a transaction.

The transaction is committed only when the client calls Message.acknowledge(), acknowledging the consumed messages.

Transacted sessions use transactions to consume and to send messages. When the client calls Session.commit(), unacknowledged messages are acknowledged and produced messages are written to the space.

Local vs. Distributed Transactions

In GigaSpaces JMS, it is possible to use local transactions and distributed transactions (Mahalo).

In general, using local transactions is more efficient than using distributed transactions.

The only limitation when using local transactions relates to the fact that a transaction is valid only for a single space. This is problematic, because GigaSpaces routs JMS messages to the spaces according to the destination name. A message to a Queue named myQueue1 might arrive at space1, while another message to a Queue named myQueue2 might arrive at space2. If a client uses a local transaction to send the two messages, it might get a TransactionException.

To overcome this problem, the client can use distributed transactions, that can span over more than one space.

When to Use Distributed Transactions

The JMS client uses a cluster that contains more than one space. The session is transacted, and transactions involve more than one destination (for message consumption and/or production):

Consuming a message from a queue, and sending a message to another destination.

Sending more than one message, to more than one destination.

You do not need to use distributed transactions when consuming from a Topic, and sending a single message to another destination.

Preparing JMS to Work with Distributed Transactions

To use Mahalo, you must first enable the Mahalo service in GigaSpaces.

To enable Mahalo, set the following XPath property in the <GigaSpaces Root>\config\gs.properties file: