[hibernate-dev] Pooled Optimiser Improvements

[Steve Ebersole]

It's hard to say without understanding the scenario where you are seeing
this as a problem.  I have some guesses as to what may be the problem, but
without understanding more about why you see this as a problem in the first
place it is hard to give you an answer.   For example, I wonder if for
environments not using multi-tenancy whether the recent changes for the
generators to support multi-tenancy might be the culprit.  If that is the
case, and those changes are in fact the underlying cause of the perf issues
you see then I think there is actually a better solution.  But again, its
hard to say unless we understand the reason this "shows up" as a perf
problem for you.

Until we hear more I think at this stage I'd vote for a separate
optimizer.  And maybe even not one that is upstream.

Also I agree with Scott that I am VERY leery of not cleaning up a
ThreadLocal.

On Fri, Dec 11, 2015 at 7:55 AM Scott Marlow <smarlow at redhat.com> wrote:

> Should this be a specialized pooled optimizer that is only used in
> environments that do not suffer from leaving the ThreadLocal around
> after the application is undeployed?  In other words, the expectation is
> that classloader leaks with this pooled optimizer are expected (e.g.
> user must restart the jvm to really undeploy the application completely).
>
> I am thinking that there are at least three typical situations:
>
> 1.  Applications are deployed in Java standalone edition.  Generally,
> when the app undeploys the jvm is shutting down.
>
> 2. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are on the global classloader path (or
> something like that).  On each shared container thread, there would be
> one Optimizer for all deployed applications.  I wonder if instead, we
> would want one Optimizer instance per Hibernate SessionFactory
> associated with the many container threads?
>
> 3. Applications are deployed as part of some container (e.g. an EE
> server) and the Hibernate jars are deployed with the application. The
> ThreadLocals are associated with threads that are shared by different
> deployed applications. The application classloader contains the
> Hibernate classes. Each deployed application has its own Optimizer
> threadlocal. On each shared container thread, there would be one
> Optimizer per application (since each application has its Optimizer TL).
>   Like (2), there would be sharing of the same Optimizer with the many
> application session factories.  Should we instead have an optimizer per
> session factory?
>
> Scott
>
> On 12/10/2015 11:31 PM, Stuart Douglas wrote:
> > Hello,
> >
> > I have been working on a change to the pooled optimizer that we have
> been seeing good performance results with. Basically it hands out blocks of
> ID's to a thread local, rather than having every thread contend on the lock
> every time an ID is required.
> >
> >
> https://github.com/hibernate/hibernate-orm/compare/master...stuartwdouglas:pooled-optimiser-hack
> >
> > What would I need to do to get a change like this in? In particular:
> >
> > - Does it need to be a new type of optimizer, or is modifying the
> existing one like I have done OK?
> > - How should it be configured?
> >
> > I am happy to do up a PR for this, but I am just not really sure what
> would be required to get it to a point where it would be acceptable for
> inclusion.
> >
> > Stuart
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>