[infinispan-dev] ISPN-359 and grouping entries for distribution

[Mircea Markus]

On 13 Apr 2010, at 13:08, Manik Surtani wrote:

> 
> On 13 Apr 2010, at 10:54, Mircea Markus wrote:
> 
>>> 
>>> since this will *not* work.  The cache still primarily is a collection of K -> V mappings and in the above case the last 2 lines will effectively overwrite the 1st 2 lines.
>> "name" will only appear once in the cluster, (on different location though), right?
> 
> Yes, and hence the effective "overwriting" of the previous name.
> 
>> Generally speaking I'm curious on how this scenario is handled:
>> node A: cache.inGroup("a").put("key","something");
>> node B: . assertEquals("something" ,cache.get("key")); //this assert is correct
> 
> The interceptor would create these mappings on a put:
> 
> K -> G
> G -> AtomicMap{K -> V}
> 
> and for a get:
> return get(get(K)).get(K)
> 
> so in your example, after the put, you will find:
> 
> "key" -> "a"
> "a" -> AtomicMap{"key" -> "something"}
> 
> Now when you do the get, the interceptor would:
> 
> grpId = get("key") 
where are you keeping this key to group mapping? I guess this should be present on all nodes
> atomicMap = get(grpId)
won't this fetch all the atomic map over for all the calls? 
> return atomicMap.get("key")
> 
> 
> "All problems in computer science can be solved by another level of indirection" - David Wheeler
"For every complex problem, there is a solution that is simple, neat and wrong" - H.L. Mencken 
(don't think this is the case for this, but I couldn't help it :D ) 
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev