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

[galder at jboss.org]

See below:

----- "Manik Surtani" <manik at jboss.org> wrote:

> On 13 Apr 2010, at 11:01, Manik Surtani wrote:
> 
> > 
> > On 13 Apr 2010, at 10:50, Sanne Grinovero wrote:
> > 
> >> 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.
> > 
> > 
> > Yes; how do we make sure no one falls into this trap?  :)  How
> about:
> > 
> > cache.affinityKey("Blah").put(k, v)
> > 
> > The problem with "group" or even location/locality/colocation is
> that they can all be misconstrued to mean "scope".  With something
> like "affinity", I suppose it is clearer?
> 
> Here is an alternative - *do* we want to support scoping?  By this, I
> mean:
> 
> cache.withAffinityKey("k1").put("name", "Manik");
> cache.withAffinityKey("k1").put("country", "UK");
> 
> cache.withAffinityKey("k2").put("name", "Sanne");
> cache.withAffinityKey("k2").put("country", "IT");
> 
> will be allowed and the two will not overwrite each other, *but* you
> cannot retrieve stuff by simply doing:
> 
> cache.get("name") anymore.  You would have to do:
> 
> cache.withAffinityKey("k1").get("name").  Simply doing a
> cache.get("name") will return a null.
> 
> What do people prefer?

Not sure I like that. Reminds me of JBC's cache.getNode("k1").get("name"). I think affinity should be limited to location. If u want scoping, I think we should come up with something else, or direct users to use atomic hash maps.


> 
> Cheers
> Manik
> 
> --
> 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