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 <sdoug...@redhat.com> wrote: >> >> >> ----- Original Message ----- >>> From: "Scott Marlow" <smar...@redhat.com> >>> To: "Stuart Douglas" <sdoug...@redhat.com>, hibernate-dev@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@lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> > >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >_______________________________________________ >hibernate-dev mailing list >hibernate-dev@lists.jboss.org >https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
