[infinispan-dev] replacing the (FineGrained)AtomicMap with grouping

[Mircea Markus]

> On 20 Sep 2013, at 21:38, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> Well, I have always wanted a way to only read some keys from a FGAM. Sort of like a projection. 

Yep, the key filter would do just that :-)

> 
>> On 20 sept. 2013, at 21:14, Randall Hauch <rhauch at 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 at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev