HibernateOptimisticLockingFailureException marks connection as 'closed'?

Question

I'm getting the following stack trace:

org.springframework.orm.hibernate3.HibernateOptimisticLockingFailureException: Object of class [com.btfin.wrapcore.request.MFRequest] with identifier [2850448]: optimistic locking failed; nested exception is org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.btfin.wrapcore.request.MFRequest#2850448]
  at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:672)
  at org.springframework.orm.hibernate3.HibernateTransactionManager.convertHibernateAccessException(HibernateTransactionManager.java:793)

Which is due to an optimistic locking exception. I can address the root cause of this.

My question is - in this scenario - the exception handling sets the database connection to 'closed'. (Which causes issues with my connection pool).

What is the pattern for handling a database exception like HibernateOptimisticLockingFailureException that bubbles up through spring and hibernate and returns a closed connection?

Do you know the part in the Spring/Hibernate code that sets the connection to closed?

Answer 1

Hibernate Docs clearly state that if any exception occur while working with the Session, the Session can't be reused afterwards. Moreover, each Session can encompass several transactions and after each transaction commits - the same happens, the connection is closed.

But while using a connection pool, the connection is not literally closed, when close() method is invoked, the connection is returned to the pool without physical closing:

when an application closes its connection, the underlying physical connection is recycled rather than being closed.

So if you have problems with the connection being physically closed, I would rather pay more attention to the pool, not to Hibernate or Spring - they can't do more than invoking close() which should work as I described earlier.