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