Re: [infinispan-dev] replacing the (FineGrained)AtomicMap with grouping
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev