[hibernate-dev] Using AS7 prepared Statement caching and Hibernate 4.0.0.Beta4 + 4.0.0.Beta5

[Steve Ebersole]

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 at hibernate.org
http://hibernate.org