On 20 Sep 2013, at 18:33, Emmanuel Bernard
<emmanuel(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev