On 19 May 2010, at 17:44, galder(a)jboss.org wrote:
----- "Manik Surtani" <manik(a)jboss.org> wrote:
> So thinking about this some more, it would seem that there is a bit
> more to this. We can add the functionality easily enough, and add the
> API to the Cache interface.
>
> But would people would reasonably expect this kind of functionality
> over Hot Rod as well? And would we need to think about exposing this
> in Hot Rod too? Or would this kind of functionality be implemented in
> the Hot Rod client if needed, so the protocol remains unchanged?
Does the affinity mean that all k,v pairs within an affinity group would be stored under
the same node in distribution mode? Or this a wrong assumption about how affinity works?
Judging by
https://jira.jboss.org/browse/ISPN-312, the grouping is more directed at
flushing, but
https://jira.jboss.org/browse/ISPN-359 suggests it could be used for
distribution.
Primarily for affinity with distribution. I.e., all entries under the same affinity key
will be colocated on the same server.
Bearing in mind I need to clarify my understanding of affinity
groups, baking it into the protocol means that is less work for clients in terms of
implementations. If you have 3 client impls, you'd have to implement it in all 3. If
it's baked in protocol, it's down to the server implementation.
Right, but it also gives clients flexibility in *how* they implement affinity.
>
> 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?
>>
>> WDYT?
>>
>> Cheers
>> --
>> Manik Surtani
>> manik(a)jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>>
http://www.infinispan.org
>>
http://www.jbosscache.org
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
>
http://www.infinispan.org
>
http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org