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

[Sanne Grinovero]

2010/4/13 Manik Surtani <manik at jboss.org>:
>
> On 13 Apr 2010, at 07:55, Emmanuel Bernard wrote:
>
> No need, Marcus had it :)
> I'd do something like
> cacheFactory.usingContext()
>   .colocateOn(groupName)
>   .getCache() (*)
> (*) assuming the ability to get a cache is
>
> Or is the collocation business something that must be done at the cache
> level temporarily / for a single operation (thus hosted on the cache
> interface)?
>
> The latter.  So something like:
> cache.inGroup("coloGrp1").put("k1", "v1");
> cache.inGroup("coloGrp1").put("k2", "v2");
> cache.inGroup("coloGrp2").put("k3", "v3");
> cache.inGroup("coloGrp2").put("k4", "v4");
> would result in k1 and k2 being placed on the same nodes, regardless of what
> the 2 keys individually hash to.  Same with k3 and k4.
> Another question (slightly off-topic) - would people then be tempted to use
> this as a scoping mechanism:
> cache.inGroup("coloGrp1").put("name", "Manik");
> cache.inGroup("coloGrp1").put("location", "London");
> cache.inGroup("coloGrp2").put("name", "Emmanuel");
> cache.inGroup("coloGrp2").put("location", "Paris");
> 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.
> Cheers
> Manik
>

rightfull concern, I wouldn't personally have expected that but I'm
biased as I follow this thread; it's not hard to imagine some people
falling in this trap.

Sanne

>
>
>
> On 12 avr. 2010, at 15:30, Vladimir Blagojevic wrote:
>
> Why don't we ping Emmanuel for an advice. He's done similar API design in
> Hibernate IIRC.
> On 2010-04-12, at 8:58 AM, Mircea Markus wrote:
>
> On 12 Apr 2010, at 15:36, Manik Surtani wrote:
>
> Re: subject (see https://jira.jboss.org/jira/browse/ISPN-359), there are a
> couple of approaches that could be taken:
> 1.  Don't use key.hashcode() as the seed in determining to which nodes an
> entry is mapped, but instead on a well-known method or annotated method
> (e.g., int getGroupID() or a method annotated with @GroupId).  The way I see
> it, this approach has:
> + Will work, no additional overheads of AtomicMaps
> - Cost (reflection)
> - Intrusive (what if users have no control over the key class, e.g., String
> keys?)
> 2.  Additional API methods on the cache - cache.put(K, V, G),
> cache.putAll(Map, G), etc.
> + Non-intrusive
> - Overhead of AtomicMaps + additional entries for mappings
> + or - (depending on how you look at it) all keys in the group will be
> locked together, etc, a side-effect of using AtomicMaps
> My pref is for approach #2.  In terms of implementation, here is what I have
> in mind:
> * A GroupingInterceptor that intercepts the call early on if the call is a
> put(K, V, G) or something similar.
> * Breaks up the call to a put(K, G) and a getAtomicMap(G).put(K, V).
>  Wrapped in a tx to ensure atomicity.
> * get(K), etc intercepted as well, replaced with getAtomicMap(get(K)).get(K)
> * remove(K), etc intercepted with getAtomicMap(get(K)).remove(K)
> One of the issues with the API approach is that it heavily pollutes the
> Cache API.  It will double the number of put() methods on Cache (currently
> 18 variants of put, including ones that take in lifespans and maxIdles,
> async versions that return futures, etc.)  Perhaps this could be in an
> additional sub-interface interface?  GroupedCache?  Or is this degree of
> method overloading not too confusing?
>
> what about using an Flag-like api?
> cache.inGroup("groupName").put(...).
> or an "parametrized" flag:
> cache.withFlag(Flags.getColocateFlag("grouName").put(...)
> as long as we can create "parametrized" flags as bellow, I like the second
> approach
>
> Cheers,
> --
> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> 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
>