See https://hibernate.zulipchat.com/#narrow/stream/132094-hibernate-orm-dev/topic/HHH-14326

It turns out we already close these statements upon session closing: they are registered through org.hibernate.resource.jdbc.internal.ResourceRegistryStandardImpl#register(java.sql.Statement, boolean), then closed through org.hibernate.resource.jdbc.internal.ResourceRegistryStandardImpl#releaseResources, which is indirectly called by Session.close.

However, when using JTA in Quarkus (and probably elsewhere), connections are closed on commit, and the commit happens before the session is closed. So the connection is indeed closed before we get a chance to close the statement.

Maybe, in JTA mode, we should call org.hibernate.resource.jdbc.internal.ResourceRegistryStandardImpl#releaseResources before commit/rollback?

I just had a look, and we cannot close the statement just after its execution, because the statement needs to be open when users subsequently retrieve results through getOutputParameterValue . We don’t have a close method exposed to users on StoredProcedureQuery either.

With that in mind, our only solutions are:

1. Retrieving all output parameters upon execution, so that we don’t need the statement anymore and can close it immediately.
   While that could work, I could see this breaking existing applications, for example because an output parameter wasn’t retrieved in application code, and its retrieval fails because of some typing of formatting issue.

2. Having some sort of automatic cleaning of previously executed statements, for example upon Session close. I’m guessing we already have something like that somewhere, but that’ll require a bit more investigation.

See also https://github.com/eclipse-ee4j/jpa-api/issues/162