I think I solved that problem. The reason was that i was doing a factory = new ClassPathXmlApplicationContext(configLocation) within every onMessage and using it to initialize my sender bean. The CachingConnectionFactory works fine.
I think I solved that problem. The reason was that i was doing a factory = new ClassPathXmlApplicationContext(configLocation) within every onMessage and using it to initialize my sender bean. The CachingConnectionFactory works fine.
Ah; good.I think I solved that problem.
Regarding rollback; if the listener throws an exception, the transaction will be rolled back; if it exits normally, it will be committed.
Gary P. Russell
Spring Integration Team
SpringSource, a division of VMware
One last question..
if I use dmlc.start () ( Connection 1 ) and within the onMessage() do a jmsTemplate.send() (Connection 2 )
if an exception occurs in Connection 2 will the message sent on Connection 1 get RolledBack safely?
I guess my question is, Is this completely Atomic (( connection1->session.rollback ) and (connection2->session.rollback))
The same question for commit(), will the commit be atomic too? Since they are two different transactions taking place on Connections that are on different threads can we guarantee that they will either happen together or not happen at all without using an external Transaction Manager?
Does the dmlc guarantee this?
There still seems to be some confusion. What do you mean by connection 1 and connection 2? There is only one connection if you use a (Simple|Caching)ConnectionFactory.
* If the session is transacted and
* if the jmsTemplate send is done in onMessage(), it will use the same session and will be atomic and the receive() and any other jmsTemplate operations will be either committed or rolled back.
If you do the send on a separate thread, session, connection, whatever; then, no, they won't be atomic.
You cannot have an atomic transaction across multiple sessions or connections.
To summarize, the DMLC does a receive, binds the session to the thread; the JmsTemplate (when running on the same thread), will use the same session; when onMessage() returns, the transaction is commited (or rolled back if an exception is thrown).
Gary P. Russell
Spring Integration Team
SpringSource, a division of VMware
Thanks for clarifying that Gary, As long as the receive() and the onMessage() calls take place on the same thread ( and consequently same session/connection because I use the CachingConnectionFactory), my use case is met.