On 20 Sep 2013, at 21:38, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
Well, I have always wanted a way to only read some keys from a FGAM. Sort of like a
projection.
> On 20 sept. 2013, at 21:14, Randall Hauch <rhauch(a)redhat.com> wrote:
>
> IMO, the primary benefit of the FGAM is that you can aggregate your entries into a
single entry that is a real aggregate: read the map and you get all the FGAM's entries
in one fell swoop. IIUC, your proposal loses this capability for a single read of all
aggregate parts. Is that right?
>
>> On Sep 20, 2013, at 11:49 AM, Mircea Markus <mmarkus(a)redhat.com> wrote:
>>
>> Hi,
>>
>> Most of the FGAM functionality can be achieved with grouping, by using the FGAM
key as a grouping key.
>> The single bit that seems to be missing from grouping to equivalent the
functionality of FGAM is obtaining all the entries under a single group. IOW a method
like:
>>
>> Map<K,V> groupedKeys = Cache.getGroup(groupingKey, KeyFilter);
>>
>> This can be relatively easily implemented with the same performance as an
AtomicMap lookup.
>>
>> Some other differences worth mentioning:
>> - the cache would contain more entries in the grouping API approach. Not sure if
this is really a problem though.
>> - in order to assure REPEATABLE_READ, the AM (including values) is brought on the
node that reads it (does't apply to FGAM). Not nice.
>> - people won't be able to lock an entire group (the equivalent of locking a
AM key). I don't think this is a critical requirement, and also can be worked around.
Or added as a built in function if needed.
>>
>> I find the idea of dropping FGAM and only using grouping very tempting:
>> - there is logic duplication between Grouping and (FG)AM (the locality, fine
grained locking) that would be removed
>> - FGAM and AM semantic is a bit ambiguous in corner cases
>> - having a Cache.getGroup does make sense in a general case
>> - reduce the code base
>>
>> What do people think?
>>
>> Cheers,
>> --
>> Mircea Markus
>> Infinispan lead (
www.infinispan.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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev