It looks to me like HibernateSessionManagerImpl has an important bug: it
should not be retaining the transaction after commit() or rollback(). Once
you do a commit, Hibernate loses track of the transaction (see
JDBCContext.afterTransactionCompletion), which causes Hibernate not to
auto-flush before a query, which was causing baffling failures of my unit
tests.
Currently (5.0.13), HibernateSessionManagerImpl.commit does this:
transaction.rollback();
transaction.begin();
Instead, I think it should do this:
transaction.rollback();
transaction = session.beginTransaction();
Or, more clean, don't even keep a reference to the transaction:
session.getTransaction().commit();
session.beginTransaction();
When I make these changes, my tests pass. Note that you will see problems
from this only if you do more work in a session after committing that
session's transaction. Since most requests will close the session
immediately after committing the transaction, they won't see this problem.
My tests were doing several commits. I also have some long-running batch
operations that do many intermediate commits; I'd expect them to fail,
though I haven't tried them yet.
--
View this message in context:
http://www.nabble.com/T5%3A-HibernateSessionManagerImpl-retains-stale-transaction-tp18761651p18761651.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
