[infinispan-dev] ISPN-359 and grouping entries for distribution
galder at jboss.org
galder at jboss.org
Wed May 19 12:31:14 EDT 2010
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
More information about the infinispan-dev
mailing list