Transactional Message Listener Container
Similar to JmsTemplate, declaring the message listener container as a Spring bean with appropriate properties set will make it transactional. Listing 18-24 shows the appropriate properties in the message listener container which can be used to make it transactional.
Listing 18-24. Making message listener container transactional
|
1 2 3 4 5 |
<jms:listener-container acknowledge=”transacted”> <jms:listener … /> </jms:listener-container> |
Note: The Listing 18-24 uses “jms” namespace which highly simplifies the spring configuration.
In place of using JMS provided transactional behavior, if you would like to use any other transaction manager, configure this new transaction manager as a Spring bean and then reference it from the message listener container as shown in Listing 18-25 below.
Listing 18-25. Making message listener container transactional using other transaction manager
|
1 2 3 4 5 |
<jms:listener-container transaction-manager=”transactionManager”> <jms:listener … /> </jms:listener-container> |
Note: Since transacted session and acknowledge mode are mutually exclusive, Spring “jms” namespace specifies them in a single attribute called as “acknowledge”. The values specified can be “auto”, “client” or “dups_ok” for acknowledge mode and “transacted” for transacted session.
Important thing to note here is that, the transaction starts soon after receiving the message. Setting the JTA transaction manager in the message listener container makes it fully XA. Whether you really want full XA in your application is purely application dependent as XA can be costly in certain aspects.
Why transaction is required?
Not having transaction in your application having JMS resources could result in having duplicate messages in your application. The criticality of duplicate messages is purely dependent on your application and could be ignored completely or could be a big potential threat.
Even after having local transactional JMS resources as seen in previous section, you could still have duplicate messages accumulating in your application.
So how can there be a case of duplicate messages even after having local transactional JMS resources? Let’s take an example as detailed below which could result in duplicate messages in which the JMS resources are transactional.
In Figure 18-10, the below are the various steps which happened, were at the end of it, there could be duplicate messages accumulating in your application:
- The JMS transaction starts
- The destination object receives the message
- The DB transaction starts
- The DB stores the message
- Now since DB activity is over, DB transaction commits
- Now due to some reason, the JMS transaction fails and the transaction is roll-backed.
In this case the message exists in Db as well as in queue resulting in duplicate message accumulating in your application. If not taken care of, it could be that your destination will not get empty while your DB slowly is filled up. This is one such scenario in which duplicate message creation could happen.
Duplicate Message Handling
Now that you have a possibility of accumulating duplicate messages in your application even when having local transactional JMS resources, what are the best ways to handle these? Two ways are:
- Use XA transactions is the only way to guarantee once-and-once-only delivery of message (In the next section, “Global Transaction Management” we will see this in detail)
- Detect duplicate messages programmatically and handle it as much as possible. This is not a full-proof solution but it is not bad either. Here are the steps which you can use in your program to check for duplicates and handle it accordingly:
- When a message arrives, check if it is a re-delivery by doing the following programmatically as shown in Listing 18-26 below.
Listing 18-26. Programmatically checking if the message is re-delivered
|
1 2 3 |
if(message.getJMSRedelivered()){ //Handle it accordingly. } |
- If the message is not re-delivered, process the message.
- If the message is re-delivered check if you have already processed. This is according to your business logic. Do appropriate programmatic checks to see if the message is processed earlier (do appropriate queries in your business layer and find it out).
- If the message is not processes earlier, process the message.
Page Visitors: 16788
Tomcy John
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
First of all I would like to say fantastic blog! I had a quick question which I’d like to ask if you don’t mind. I was interested to know how you center yourself and clear your head before writing. I have had difficulty clearing my mind in getting my ideas out there. I do enjoy writing but it just seems like the first 10 to 15 minutes are usually wasted just trying to figure out how to begin. Any recommendations or tips? Thank you!|