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

Emmanuel Bernard emmanuel at hibernate.org
Fri Sep 20 12:56:45 EDT 2013


I sort of see how we could replace it but we do make use of the FGAM to
represent an Hibernate OGM dehydrated entity with one property per map
entry.
>From what you are describing we would get an alternative solution but
that would mean more memory strain and object creation. That will
negatively impact the Infinispan backend.

Also I don't remember if we use the key lock but at some point we will.
I imagine a workaround is to lock the id property.

OGM could live with it but it seems the usage is rendered more
complicated and users having the same style of requirements would need
to be more expert (more complex APIs).

Emmanuel

On Fri 2013-09-20 17:49, Mircea Markus 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


More information about the infinispan-dev mailing list