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

[Jason T. Greene]

On 5/19/11 5:11 AM, Manik Surtani wrote:
> Guys - what are we talking about?  Specifying ClassLoaders is only
> meaningful if storeAsBinary is set to true.
>
> In general, any situation where you have code booted off different
> ClassLoaders running in the same JVM and sharing the same cache (or
> cache manager), you would *need* to set storeAsBinary to true to get
> around deserialization issues on remote nodes.
>
> StoreAsBinary = false only really works for trivial cases where
> caches/cache managers run in environments where only one cache loader
> is in effect.  I.e., *not* JBoss/Java EE/Hibernate/OSGi/etc.  This is
> one of the reasons why we considered setting storeAsBinary to true by
> default (and we see similar techniques in competing data grids).

With AS7 we actually have the ability now that you could actually locate 
the proper module/deployment that had the classes to deserialize, and 
you could even wait on the corresponding service for them to become 
available. OSGi also has a similar ability.

The problem though is that the deserialization thread would have to 
potentially block, so you would have to do something like have a tiny 
timeout and fallback to the storeAsBinary=true approach if the module 
isnt available yet.

Even worse is if someone constructed their own classloader, or used a 
framework that defined its own classloading, those types would not be 
accessible for the same reasons as in the past.

Lastly, it would require more work to implement since it would have to 
be tailored for each environment (OSGI and AS7 and so on).

So I think to ever justify it, it would take some very convincing 
numbers that eager deserialization is indeed better.

-- 
Jason T. Greene
JBoss, a division of Red Hat