JMS Transactions

Interaction to JMS is by definition stateful in nature. While interacting, it’s necessary to preserve the ACID (Atomic, Consistent, Isolated and Durable) principles. For any enterprise application preserving ACID principle is very important and should be considered seriously. One way of doing this preservation is by using transactions. The key to JMS transaction is JMS session. Following section discusses JMS session in detail.

JMS Session

JMS session can be called as a “unit of work” and keeps track of all the activities. It is created from JMS connection and the Connection interface definition is as shown in Listing 18-22 below.

Listing 18-22. Connection interface definition

While creating session using the “createSession” method in connection object, if you pass “transacted” value as true, the session becomes transactional in nature. On session there are two important methods related to transaction namely commit() and rollback() methods. For session which are trasnactional in nature, the second attribute in createSession() method namely “acknowledgeMode” is ignored. If you don’t want to load your application operation with truncations, you can use the acknowledge mode to track the outcome of message processing. Next section covers acknowledge mode of JMS transaction in detail.

Acknowledge Mode

You specify the acknowledgement modes when creating a JMS session, as seen in the previous section. There are three main acknowledge modes available which are summarized as below:

• Auto mode (AUTO_ACKNOWLEDGE) – When a session uses this mode, the messages sent or received from the session are automatically acknowledged. It is the simplest mode and enables once-only message delivery guaranteed. It is usually set when there has been a successful receive() or onMessage() method. This mode is used as default by Spring with having any configuration. Successful reception of message marks the message as delivered and it is removed from the queue destination. Due to this it is not redelivered which avoids duplicates. This mode is a bit slow as the acknowledgement is send after every successful message delivery. The messages can be lost is there is an exception after delivery during its processing.
• Duplicates okay mode (DUPS_OK_ACKNOWLEDGE) – When a session uses this mode, the messages sent or received from the session are automatically acknowledged just like auto mode, although lazily. Under rare circumstances, the messages might be delivered more than once. This mode enables at-least-once message delivery guarantee. Much better performance than auto mode.
• Client mode (CLIENT_ACKNOWLEDGE) – When a session uses this mode, the messages sent or received from the session are not acknowledged automatically. The application must acknowledge the receipt of the message. This mode gives the application complete control over message acknowledgement but results in increased code complexity. The client has to call Message.acknowledge() method explicitly. In this mode client takes responsibility of acknowledging. Client can call the acknowledge() after successful processing of multiple messages.

All these modes are defined as final int’s in the session class.

JMS Transaction Types

Before going through this section, I would urge the reader to glance through first half of Chapter 9, “Transaction Management” to understand or rather refresh transaction related concepts and continue reading this section.

Now that you have understood the concepts involved in a JMS transaction, we will now cover the various flavors of JMS transaction which Spring supports. They are:

• No Transaction – messages produced and consumed without transaction coming into picture. Completely relies on the acknowledge mode to check for success or failure. Not suitable for an enterprise application but can be considered if the application is not a complete message oriented one and can have message failures and losses without hampering its core business operation.
• Local Transaction – while creating the session object from the connection object, if you pass the first parameter to createSession() method as “true”, you would automatically get your session to be transactional in nature. In the case of local transactions, the messages are acknowledge on transaction commit.
• XA Transaction – an XA transaction, in simpler terms, is a “global transaction” that may span multiple resources (database, JMS etc.). The parameters passed while creating session is completely ignored in this case.

Is it so simple? The answer to this is “NO”. Just skim through the following sections one-by-one and slowly tie together these sections to better understand the various concepts. To have a step-by-step explanation of terms seems a bit hard here, that’s why I am taking this approach. I am sure while you keep reading following sections; you will have to turn back pages, read already read sections again to have a clear understanding. I think this is the right way and I would urge you to be a bit patient if you don’t understand nor cannot tie things unrelated sections together immediately. You can rest assure that by the time you reach this Chapters summary you would have tied these various unrelated sections.

Spring’s support for Transactional JMS Resource

Spring supports transactional behavior to JMS resources. From Spring’s context two important resource having transactional behavior are the helper class JmsTemplate and the listener containers. We will see these two JMS resources can be made transactional in the Spring context.

Transactional JmsTemplate

Declaring the JmsTemplate as a Spring bean with appropriate properties set will make JmsTemplate transactional. Listing 18-23 shows the appropriate properties in the JmsTemplate which can be used to make the helper class transactional.

Listing 18-23. Making JmsTemplate transactional

Two properties namely “sessionTransacted” and “sessionAcknowledgeMode” are the ones which gives the helper class transactional behaviour. Default settings for JMS Sessions are “not transacted” and “auto-acknowledge”. As defined by the J2EE specification, the transaction and acknowledgement parameters are ignored when a JMS Session is created inside an active transaction, no matter if a JTA transaction or a Spring-managed transaction.

The property “sessionTransacted” is used to set the transaction mode that is used when creating a JMS Session and the default value is “false”.

The property “sessionAcknowledgeMode” is used to set the JMS acknowledgement mode that is used when creating a JMS Session to send a message and the default value is Default is Session.AUTO_ACKNOWLEDGE. Vendor-specific extensions to the acknowledgment mode can be set here.

Page Visitors: 16772

The following two tabs change content below.

• Bio
• Latest Posts

Tomcy John

Blogger & Author at javacodebook

He is an Enterprise Java Specialist holding a degree in Engineering (B-Tech) with over 10 years of experience in several industries. He's currently working as Principal Architect at Emirates Group IT since 2005. Prior to this he has worked with Oracle Corporation and Ernst & Young. His main specialization is on various web technologies and acts as chief mentor and Architect to facilitate incorporating Spring as Corporate Standard in the organization.

Latest posts by Tomcy John (see all)

• A Guide to Continuous Improvement for Architects - February 2, 2023
• Cloud-first Architecture Strategy - January 26, 2023
• Architecture Strategy and how to create One - January 24, 2023