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

Manik Surtani manik at jboss.org
Mon Apr 12 09:34:22 EDT 2010


On 12 Apr 2010, at 14:08, Mircea Markus wrote:

> Another way to do it is by specifying an associator (not my idea TBH [1]).
> This is non-intrusive and no-api changes as well.

Is it non-intrusive?  Doesn't this mean that keys need to implement an interface?


> Cheers.
> Mircea
> 
> [1] http://coherence.oracle.com/display/COH35UG/Data+Affinity 
> 
> 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?
>> 
>> 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

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100412/8f1a8e6d/attachment-0002.html 


More information about the infinispan-dev mailing list