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.
No announcement yet.
Nested Transactions and propogation_requiredPage Title Module
Re: Hibernate, OpenSessionInViewFilter, J2EE transaction man
Originally posted by kbaum
I think the problem is occuring in this else block in SessionFactoryUtils
Indeed, that code is not correct when running with OpenSessionInViewFilter: It needs to return the default thread-bound Session if no JTA transaction is active. I've just fixed this; actually, I've recently fixed another Hibernate/JTA issue in SessionFactoryUtils too.
In general, Colin is right that you should execute within transactions in any case. If you perform non-transactional data access operations in combination with OpenSessionInViewFilter and JTA, you should use the most current SessionFactoryUtils version from CVS. If you have the chance, please give the latter a try!
To add to Juergen's note; Based on your previous message I think you still think that your methods are transactional, but as the log shows, they are not. Juergen's fix will of course resolve the issue with getting a new Session instead of using the old one, but your code will still be non-transactional, so you need to look at your regexes to see why the methods in question are note being treated as transactional.
I realize the methods I am speaking of are not using Transactions. My regular expressions only matche DAO methods beginning with save, update, or delete. For the methods beginning with find, I do not start a transaction because they are only reading from the database. I am under the impression that starting a transaction for methods that only read from the database is unneccessary and even a performance hit. Is this wrong?
I think it really depends on the app and usage scenario as to whether you'd want to make read methods non-transactional. Generally, I think it's easierand better to start with things transactional, then the config is simpler, and there are no issues with inconsitent data. Even if you are only reading data, if data is being read in multiple operations it can be inconsistent if you are non-transactional. Then if you start needing to optimize, you can do things like reading non-transactionally. Don't forget also that you can also do things like mark a transaction as read only, which will make the tx never commit, but still ensure that the data you read is consistent in that batch...
What I would recommend you do is check out Spring from CVS and take a look at the ejbtest sample application which is under autobuilds.
In there are 3 variations of one ejb, with the following setup (all running in a JTA environment and coordinating with JTA):
- CMT (Container Managed Transactions) wrapping the EJB, delegating to a POJO object wrapped with Spring Transactions. This ultimately performs some hibernate operations
- CMT wrapping the EJB, delegating to a POJO object not wapped with any Spring transactions, ultimately doing Hibernate ops again
- NO CMT wrapping the EJB, delegating to a POJO object wrapped with Spring TX.
The app is set up for JBoss, and works fine. I did a bit of cleanup this afternoon and verified that. If I was you, I would build the app, deploy it (read the readme.txt file in it), and verify that the 'test' target in the build file can properly run an integration test against it, and take it from there, trying to figure out what the difference is in your applicaiton. Something in your setup is not correct, it's that simple...
Btw, please, in the future, try not to hijack an existing topic that somebody else has already started, to ask an unrelated question, as you did here. It is is confusing to try to keep track of both threads in the same topic. Just start a new topic for your own question.
Tahnks for your quick response i will check it tommorrow. Meanwhile please accept my apologies for posting in an irrelevant thread, it was not intended i actually got impression that from one reply that it is related but that was actually my fault.. again sorry i will never repeat this. Thanks for great framework ..Spring Team also for very good support forrums.