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

Dan Berindei dan.berindei at gmail.com
Wed Jun 8 06:42:49 EDT 2011


On Wed, Jun 8, 2011 at 12:48 PM, Manik Surtani <manik at jboss.org> wrote:
> 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.
>

The CacheDelegate instance returned by CM.getCache() is shared between
all the users that called getCache(), so if we want different users to
have different classloaders I think we need another Cache wrapper
class that will set/reset the TCCL.


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



More information about the infinispan-dev mailing list