Announcement Announcement Module
Collapse
No announcement yet.
JDBC Connection leak with Spring + Hibernate + exhausted pool Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JDBC Connection leak with Spring + Hibernate + exhausted pool

    A JDBC Connection becomes garbage but isn't closed, when using Hibernate together with Spring transaction management and a connection pool that's temporarily exhausted. For details, see below. This raises several questions:

    Why does SpringTransactionFactory choose the connection release mode ON_CLOSE as the default? Would I lose something by setting it to AFTER_TRANSACTION? SPR-2022 suggests after_transaction would prevent using custom isolation levels or read-only connections (which seems bad). But I'm not sure that's still true in recent versions of Spring.

    Why does TransactionAwareDataSourceProxy try to allocate a connection repeatedly, within a single transaction? I'm tempted to make it allocate only once, by injecting it with a DataSource that produces a Connection that either works or (if allocation fails) throws a SQLException from every method except close(). Would that cause problems?

    Here's the problem scenario in detail. Hibernate gets a connection from TransactionAwareDataSourceProxy. The first two calls to the connection (getAutoCommit and isClosed) throw SQLException, because they fail to get a connection from the pool. But the next call gets a connection, so it and subsequent calls don't throw exceptions. Sadly, Hibernate fails to close the connection, because it got confused by the exceptions.

    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.

    There's a Hibernate discussion thread about this.
Working...
X