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)