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. 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: