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

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.