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

[Brian Stansberry]

On 04/13/2010 05:08 AM, 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}
>

What if K itself is an AtomicMap (which in the session case being 
discussed with Vladimir Ralev, it will be)?

> 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")
> atomicMap = get(grpId)
> return atomicMap.get("key")
>
>
> "All problems in computer science can be solved by another level of indirection" - David Wheeler
>
> --
> 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


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat