I work on two resources (JMS & JDBC). I use WebsphereUowTransactionManager. But JMS transactions are getting committed prior to the JMS transaction. This seems to be the default behavior. Is there a way to have a reverse behavior where JDBC is committed prior to JMS commit..??
Spring supports this type of scenario, basically the scenario where database is committed before JMS is called "best effort strategy" for managing transaction involving JDBC & JMS without using JTA. If you are using the jms listener-container provided by Spring for consumption of messages, then for the acknowledge property you need to specify "transacted". In this case Spring will then synchronize with transaction started by local transaction manager like DataSourceTransactionManager. I am not very sure if it will work with WebsphereUowTransactionManager as it is implementation of JTA transaction manger from IBM. With WebsphereUowTransactionManager you also have a option of using JTA transactions.
Your approach should work, as Spring internally will also be doing something like this. However the downside is that you will have to write code for doing all this which can introduce potential bugs, cause maintainence issues & is not scalable if you have a lot of places in your app where JMS & database transactions need to work.
I would try to use Spring to do this for me & will revert back to writing code if Spring is not able to cater to the scenario.
I tried various other configuration changes where i could make JDBC commit prior to JMS commit. I use JMSTemplate102 and tried using JTATransactionManager, WebSphereUowTransactionManager but nothin turned out to be helpful.
I had got it working with jms listener container & DataSourceTransactionManager. Have shared configuration below. I am not very sure if it will work with JTA. In case you are not using XA transactions you can use DataSourceTransactionManager.
Thanks for the response. I am using XA transaction along with JDBC. So i guess, in order to override the default approach of JMS-COMMIT-FIRST-FOLLOWED-BY-JDBC-COMMIT, i indeed have to go in for nexted transactions.
The approach i told is working, but it may not be the best approach i guess.
Do you have 2 different databases that requires XA transactions. Basically a situation where 2 resource managers are being used require XA transactions. In case you are already using transactions then JMS can also participate in JMS transaction. In this case the "best effort strategy" of committing database before JMS is not required. For JTA to work you need to use XA aware resources (drivers for JDBC & connection factories for JMS).
I have a single Database and a single Queue. I already use both of them within a transaction. My problem is, JMS gets committed first followed by JDBC. So application listening to queue reacts first and searchs for data in Database and ends up in No Data Found Exception. However , by redelivering the message in the queue, the issue is handled. But it is not what desired.