]
John Kristian commented on HHH-4802:
------------------------------------
I moved the test case to
Connection leak with Spring, JDBC and exhausted pool
----------------------------------------------------
Key: HHH-4802
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4802
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: Hibernate 3.3.2
Spring 2.5.6
Reporter: John Kristian
Attachments: testHibernate.zip
Session.close fails to close a JDBC Connection, if the first two calls to the connection
(getAutoCommit and isClosed) throw SQLException and subsequent calls don't throw
exceptions.
That's unusual behavior for a Connection, but it happens. One example is a Spring
TransactionAwareDataSourceProxy, with a connection pool that's temporarily exhausted.
Spring attempts to get a connection from the pool on each call to a Connection method. The
first two calls may fail because the pool is exhausted, but the third call may allocate a
connection and succeed. Other connection pooling systems behave this way.
This creates a vicious cycle: if the pool is temporarily exhausted, Hibernate leaks a
connection, which makes it more likely that the pool will become exhausted. If demand for
connections doesn't stop, all the connections will leak and the pool will be
permanently exhausted.
The attached test case is also available via Mercurial `hg clone
http://bitbucket.org/jmkristian/example` (in the testHibernate subdirectory).
I posted to
https://forum.hibernate.org/viewtopic.php?f=1&t=1001942 but saw no
response.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: