Re: [infinispan-dev] [Pull Request] Modular Classloading Compatibility
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