JDBC statement is not closed when DeferredResultSetAccess fails to execute a query
Description
In org.hibernate.sql.exec.internal.JdbcSelectExecutorStandardImpl#doExecuteQuery , DeferredResultSetAccess (and thus the underlying JDBC statement) does not get released when resolveJdbcValuesSource throws an exception.
In practice this is not a big issue as the JDBC driver or connection pool (e.g. Agroal) will likely close statements on connection release, but it does lead to annoying warnings with Agroal in particular.
The leak can be reproduced for example by trying to execute specific queries in transactions:
a query with parameters whose type don’t match the SQL, e.g. SELECT ( :param / 2 ) with param = "foo"
with the MySQL JDBC driver, a query referencing tables that don’t exist (this driver will only check this on query execution, not when preparing statements…)
In
org.hibernate.sql.exec.internal.JdbcSelectExecutorStandardImpl#doExecuteQuery,DeferredResultSetAccess(and thus the underlying JDBC statement) does not get released whenresolveJdbcValuesSourcethrows an exception.In practice this is not a big issue as the JDBC driver or connection pool (e.g. Agroal) will likely close statements on connection release, but it does lead to annoying warnings with Agroal in particular.
The leak can be reproduced for example by trying to execute specific queries in transactions:
a query with parameters whose type don’t match the SQL, e.g.
SELECT ( :param / 2 )withparam = "foo"with the MySQL JDBC driver, a query referencing tables that don’t exist (this driver will only check this on query execution, not when preparing statements…)
See also