I am debugging our webapp. It is configured to create a DataSourceTransactionManager bean and also a HibernateTransactionManager bean on startup. This is not intentional but is caused by a 3rd party dependency. The effect appears to be benign. What I’m seeing via debugging is that when we persist an object via a Hibernate based DAO – the DataSourceTransactionManager is invoked and not the HibernateTransactionManager (the beans both are called ‘transactionManager’). The Spring Javadoc implies (I think, re-reading it now) this is fine for local resources – which is our situation. I.e. its not a distributed JTA based environment.
My question is – is there any negative impact of not using the HibernateTransactionManager for ORM based persistence. I can change the config to make the HibernateTransactionManager be used via a qualifier on the @Transactional annotation on our DAOs.
Things are working fine in simple unit test, integration test setup but I am more concerned about scaling to full production volumes when we’ll have thousands of users and a high level of concurrency.
TIA,
hope this isn’t too obscure.
Spring 3.0.x BTW.
This is in the Spring 3.1 docs.
Sec 11.9 "Solutions to Common Problems".
Use the correct PlatformTransactionManager implementation based on
your choice of transactional technologies and requirements.
This would strike me as wrong and will cause problems. Without the hibernate txn manager all calls made to HibernateOperations will be outside a transaction and on a separate session, possibly using auto-commit. So it might appear that everything is fine when an error occurs you may find changes you would expect to be rolled-back aren’t.
Try the following to check
Check whether the ‘something’ appears in the DB or not.
Another check would be
You might find the last call causes an exception as the session was not kept open from the load because the enclosing txn is not managed by the hibernate txn manager.