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

Responses inline Also want to preface this with: If you haven't seen in other mailing list Read Committed is going away as it doesn't work properly in DIST (in fact AM is is really badly bugged with RC with DIST); On Fri, Sep 20, 2013 at 9:56 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: Object creation overhead shouldn't be that bad, the only real addition is each node would keep a map containing the group name pointing to the keys that are tied to that group (for entrySet etc). This allows for much better serialization performance, detailed below, since you can optimize only reading the key(s) you care about. Yeah just using a separate but shared lock would cover that pretty easily, but also opens to missed locking as it isn't implicit anymore. On Fri, Sep 20, 2013 at 1:38 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: +1 That is one benefit. However this also very costly when you are performing any operation on the AtomicMap from a node that doesn't own that value as it will have to retrieve the entire contents on every operation remotely if not owner (only once inside a given batch/tx). The current grouping API doesn't allow for aggregated keys and values, but Mircea is proposing to add the Cache.getGroup method. In that case you can control what keys you bring back if you want 1 or all for example. Just to be clear this is only for the purpose of retrieving multiple values, right? If a user is doing operations on a single key they would still use the existing get, remove, replace, etc methods on Cache right? They would just do a put based on the key of the "inner map" and they would just have to have a @Group annotation on the key or use a Grouper API? Taking the group aspect a step further I think it would be cool to have a method similar to AdvancedCache.withFlags like AdvancedCache.groupedBy that returns an AdvancedCache that always sends methods to the given node hashed by the provided group. Would this override @Group and Grouper though? I think we would still want to do a projection based view with a KeyFilter though, so users don't have to read all the values if they only want a select few. Would writes to the projection be forwarded to the real cache though? In both AM and FGAM the entire contents of the map are remotely read at the beginning of the operation as I mentioned above. Really not nice. +1 I personally don't think we need AM as there are ways to emulate it using manual locking. +1 +1 I think it definitely could use a fresh evaluation. Actually by using Groups we no longer have to use Deltas, which means that users could use Deltas for their values now as well, which AM and FGAM didn't support before.