Re: [hibernate-dev] Using AS7 prepared Statement caching and Hibernate 4.0.0.Beta4 + 4.0.0.Beta5
On 09/20/2011 09:22 AM, Scott Marlow wrote:
This went away for a while but Jeremy is now recreating this
(http://pastie.org/2563226).
Can anyone tell us how long Hibernate 4.0.0 can hold onto a
PreparedStatement? And whether its possible that Hibernate may be
holding onto a PreparedStatement for reuse after Hibernate has called
the PreparedStatement.close method?
It is possible to get "Hibernate to hold onto a PreparedStatement"
indefinitely if the application leverages scrollable result sets and
never closes them. The same is potentially true (depending on how the
prepared statement and result set connection is implemented) using
Hibernate's notion of "iterated query results" which hold open a result
set until closed.
Another case where you can see "Hibernate to hold onto a
PreparedStatement" is in the case where its JDBC batching capability is
enabled. There it holds onto a prepared statement in order to apply the
batches
Outside of those 2 cases, unless something is seriously amiss in the
Hibernate code, we should generally be using a prepared statement,
extracting any results and then immediately closing them.
This problem goes away, if the AS7 PreparedStatement cache is disabled
but for best performance, it would be nice to support using Hibernate
with a PreparedStatement cache.
Its possible that the bug is also in the AS7 PreparedStatement cache and
that we just haven't found it yet.
What do you think?
What is the type of statement that is being prepared where this issue
pops up? DML operation? A load select? A query?
Are the statement "handles" returned by the JBoss cache thread-safe? Is
threading used in whatever test causes this condition?
--
steve(a)hibernate.org
http://hibernate.org