[hibernate-dev] Pooled Optimiser Improvements

[Ståle W Pedersen]

Hi, we've done some runs now with 5.0.6-SNAPSHOT (built today) and we're 
seeing a lot more contention compared to the same build without Stuart's 
patch.
If possible I would like to see this being merged, but if it's not 
possible Steve's suggestion should also work afaik.

ståle

On 14.12.15 15:12, Sanne Grinovero wrote:
>I love Steve's idea of having a dedicated implementation for
>non-multitenant users.
>
>But +1 to also apply this improvement.
>
>Sanne
>
>On 14 December 2015 at 01:44, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Scott Marlow" <smarlow at redhat.com>
>>> To: "Stuart Douglas" <sdouglas at redhat.com>, hibernate-dev at lists.jboss.org
>>> Sent: Friday, 11 December, 2015 10:54:15 PM
>>> Subject: Re: [hibernate-dev] Pooled Optimiser Improvements
>>>
>>> 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.
>>
>> In this case it is a non-issue, as the JVM will be destroyed on shutdown.
>>
>>>
>>> 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?
>>
>> AFAIK there is one optimiser per table, not one global optimiser. On undeploy these Optimisers will no longer be referenced and should be eligible for GC, which will clean up the thread local.
>>
>> It is importable to note that this is not a static thread local, which are very prone to leaks.
>>
>>>
>>> 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?
>>
>> The same this applied here, once the application is undeployed the ThreadLocal should be eligible for GC.
>>
>> Stuart
>>
>>>
>>> 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
>_______________________________________________
>hibernate-dev mailing list
>hibernate-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/hibernate-dev