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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
