[hibernate-dev] Using AS7 prepared Statement caching and Hibernate 4.0.0.Beta4 + 4.0.0.Beta5
Gail Badner
gbadner at redhat.com
Wed Sep 21 13:30:23 EDT 2011
It is happening on an entity load, so I was assuming that it was not any of the cases mentioned where Hibernate holds onto a PreparedStatement.
----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: hibernate-dev at lists.jboss.org
> Sent: Wednesday, September 21, 2011 10:20:50 AM
> Subject: 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 at hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list