[infinispan-dev] replacing the (FineGrained)AtomicMap with grouping
Mircea Markus
mmarkus at redhat.com
Sun Sep 22 11:18:28 EDT 2013
> On 20 Sep 2013, at 18:33, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> 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.
In practical terms the overhead would be an extra reference/entry, pointing to the group object.
> 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.
Yes, that would be the workaround.
If/when needed, we can also enhance write to an entry in the group to acquire a lock on the group itself.
>
> 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).
I think the groupping API is slightly cleaner actually than the AtomiMap one, but is just a matter of taste :-)
>
> Emmanuel
Thanks for your feedback!
>
>> 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
> _______________________________________________
> 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