This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

AnnouncementAnnouncement Module

Collapse

No announcement yet.

Difference between sessionTransacted and JMSTransactionManagerPage Title Module

Difference between sessionTransacted and JMSTransactionManager

Oct 13th, 2007, 12:33 PM

Hi All,

Just a small question again....I am running ActiveMQ on Tomcat and am using Spring JMS for MDPs configured via MessageListenerAdapters....I have got a set of MDPs which connect to the underlying services....If there is an exception thrown from the service class which the MDPs access I need the message to remain in the queue...I tried using JMSTransactionManager as well as sessionTransacted=true but to no avail...The message still remains in the Q....Further reading did point out that the usage of either supports only Local Transactions.....Could anyone please give me a one-liner on what Local transactions mean ?? Is it that only errors thrown from the listener class and not the service class will ensure that the message remains in the Q? As far as the difference between the two is concerned, if I use JMS Transaction Manager is it necessary to set the sessionTransacted flag ??

I tried using JMSTransactionManager as well as sessionTransacted=true but to no avail...The message still remains in the Q.

Yes, indeed this behavior is correct!. If you are setting the session as transacted OR you are using a transaction manager, then the message will remain on the queue. Until one listener processes this message without an error.

Could anyone please give me a one-liner on what Local transactions mean ??

This is important, if your listener itself executes also another transaction. (i.e. your listener inserts a record into the database). In this case you will have two transactions which are considered as local transaction.

If you are running this setup, then you can receive a message twice for processing (listener reads the message, database inserts and commit, listener fails to commit transaction). If you can live with this situation (because you check inside the listener if your message is already processed), then you can use local transaction, demarcated through spring.

If you need to ensure that you receive a message only once, then you will need to use global transaction. In this case an external transaction manager i.e. JtaransactionManager will ensure that both resources (messaging, database) runs in one "logical transaction".