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 [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
