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

[William Burns]

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 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. That will
> negatively impact the Infinispan backend.

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.

>
> 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.

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.

>
> 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, Sep 20, 2013 at 1:38 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> Well, I have always wanted a way to only read some keys from a FGAM. Sort of like a projection.
+1
>
>> On 20 sept. 2013, at 21:14, Randall Hauch <rhauch at redhat.com> wrote:
>>
>> IMO, the primary benefit of the FGAM is that you can aggregate your entries into a single entry that is a real aggregate: read the map and you get all the FGAM's entries in one fell swoop. IIUC, your proposal loses this capability for a single read of all aggregate parts. Is that right?

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.

>>
>>> On Sep 20, 2013, at 11:49 AM, Mircea Markus <mmarkus at redhat.com> 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);

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?

>>>
>>> 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.

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.

>>> - 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.
+1 I personally don't think we need AM as there are ways to emulate it
using manual locking.
>>>
>>> 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
+1
>>> - 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
+1
>>>
>>> What do people think?

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.

>>>
>>> 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev