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

[Galder Zamarreño]

On May 19, 2011, at 11:55 AM, Galder Zamarreño wrote:

> 
> On May 19, 2011, at 11:45 AM, Galder Zamarreño wrote:
> 
>> 
>> On May 18, 2011, at 6:06 PM, Manik Surtani wrote:
>> 
>>> 2) Class loader per invocation.
>>> 
>>> I've been less than happy with this, not just because it pollutes the API but that it adds a layer of confusion.  If all use cases discussed can be solved with (1) above, then I'd prefer to just do that.
>>> 
>>> The way I see it, most user apps directly using Infinispan would only be exposed to a single class loader per cache reference (even if multiple references talk to the same cache).  
>>> 
>>> Frameworks, OTOH, are a bit tougher, Hibernate being a good example on this thread.  So this is a question for Galder - is it feasible to maintain several references to a cache, one for each app/persistence unit?
>> 
>> Sorry, missed the second part of the email, forget it my questions are irrelevant after this. 
>> 
>> I think this might be doable. Each entity/collection region has a cache associated which is built of the region factory. As long as when the region's classloader can be identified at that point and passed to the cache manager on cache retrieval, we should be Ok.
> 
> Actually Manik, for this to really work, a Cache would need to be identified not only by its name but by its classloader too, so:
> 
> cacheManager.getCache("entities", CL1)
> and
> cacheManager.getCache("entities", CL2)
> 
> would be different cache instances. The problem then is that if an RPC comes for "entities" cache and entity P1, which of the "entities" caches do I go for? You'd need to know which classloader P1 is living in the remote node and you'd have to now that at the Infinispan level to be able to store it in a non-binary format.

And not only you have the problem of how to know the classloader associated with P1, you also have to remember that the node to which P1 is replicated to might not have P1 deployed. You're back to the asymmetric cluster issue where the entity might not be deployed in the remote node ( == the cache you're talking to might not be deployed in that node).

When 2LC uses a common cache with storeAsBinary=true, we won't have this problem cos the entity can be replicated to any node and remain in binary format until the app is deployed and P1 is requested.

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache