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

[Scott Marlow]

On 09/21/2011 01:20 PM, Steve Ebersole wrote:
> 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.

Gail pointed out, that the TRACE log, shows "Closing JDBC container 
[org.hibernate.engine.jdbc.internal.JdbcResourceRegistryImpl" multiple 
times between use of the query.  So, we know that the JDBC connection is 
being closed between uses (meaning that Hibernate couldn't be reusing 
the same prepared statement with different DB connections).

Thanks for the responses.

Scott

>
>>
>> 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?
>
>