Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility

Apologies for my long absence from this thread. On 20 May 2011, at 15:28, Jason T. Greene wrote: > On 5/18/11 11:06 AM, Manik Surtani wrote: > >> >> 1) Class loader per session/cache. >> >> I like Jason/Sanne/Trustin's suggestions of a session-like contract, and specifically I think this is best achieved as a delegate to a cache, again as suggested elsewhere by Pete, etc.  E.g., >> >>      Cache<?, ?>  myCache = cacheManager.getCache("myCache", myClassLoader); > > -snip- > > I would recommend leaving this open to store other per-session configuration values (perhaps with a builder), and some of them mutable. > This will allow you to completely eliminate the ThreadLocal context stuff used today which is both faster and more robust (the gc will clean up the state for you). Are you suggesting something like:        cacheManager.withClassLoader(myClassLoader).getCache("myCache"); thus allowing future expansions such as:        cacheManager.withClassLoader(myClassLoader).withSomeOtherParam(param).getCache() ? I do like this, since it doesn't pollute the basic cache manager API methods like getCache(). > >> 2) Class loader per invocation. >> > > If this "session" notion has some mutable values, you could also make CL mutable: > > cacheSession.setClassLoader(blah); > cacheSession.setFlags(FORCE_WRITE_LOCK) > Yes, no reason why the delegate Cache can't do this.  These setters would need to exist on the Cache interface though.  For now, we should just restrict to setClassLoader(). >From an implementation perspective, given where we are with 5.0 now, I suggest we implement by holding the ClassLoader in the CacheDelegate impl, and each method invocation impl would: 1) Set TCCL with the instance's ClassLoader field 2) Do work 3) In a finally block, reset TCCL. This is just a temp measure, since I don't want to re-work how Marshallers, etc get a hold of the class loader.  They use TCCLs right now, and while sub-optimal in many ways, this approach gives us an easy mechanism to implement while still preventing any leaks, etc otherwise common with TCCLs.

Cheers Manik -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev