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