On 20 Sep 2013, at 20: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?
No, Cache.getGroup would allow you to do just that.
> 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