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
