[infinispan-dev] Integration between HotRod and OGM

[Emmanuel Bernard]

On 22 Jan 2014, at 14:48, Mircea Markus <mmarkus at redhat.com> wrote:

> 
> On Jan 22, 2014, at 1:26 PM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> Conceptually I like the grouping API better than AtomicMap as I don’t have to rely on a specific Infinispan type.
>> 
>> We do use FineGrainedAtomicMap both for the entity and the association persistence (not AtomicMap).
> 
> So you don't use the AtomicMap(vs FGAM) at all? Is there any place in which you require a lock in the whole map to be acquired?

I will be not right now.
It seems that Sanne moved both entity and association to use the FGAM to lower the lock contentions. I don’t quite remember if that was fully intentional or a side effect. Intuitively, I’d see us use AM for entities but that’s not the case.

> 
>> It is particularly critical for how we store the association navigation information. I don’t want one update to literally prevent the whole association from being updated. This is the same semantic a RDBMS has and that’s why Manik and I designed the FGAM requirements.
>> 
>> So my question is what are the differences between the grouping API and the FGAM in particular for:
>> 
>> - the amount of data sent back and forth (seems like grouping is sending the data naturally per key as “delta compared to the group"
> 
> - we'll only send the (group, key, value) for every group write. The same amount of info is sent for an FGAM.put
> 
>> - the locking level when a new entry is added to the FGAM / Grouping API
>> - the locking level when a new entry is removed to the FGAM / Grouping API
>> - the locking level when a new entry is updated to the FGAM / Grouping API
> 
> - in the case of grouping the lock object is the tuple (group, key), so the lock granularity is the same as FGAM, which under the hood build an synthetic lock object based on (FGAM, innerKey)

Don’t FGAM uses the “group” level lock when it create / delete the group? What about create / delta keys in the group (which have to be added to a list of keys in the group)?

> 
>> - the overall network verbosity
> 
> - same
> 
>> - does grouping offer the same repeatable read protection that AtomicMap offers within a transaction?
> 
> - yes, and it actually has a clearer semantics, as the grouping API is entirely built on top of the basic cache operations, instead of being a first class citizen with it's own transaction semantics.
> 
>> 
>> I think retrying as a transaction workaround is quite fragile. We can offer it as a solution but supporting or encouraging it is another story. Unless each OGM nodes do behave like a transaction but that would be wrong. I am also concerned about reading data form a group that are inconsistent.
> 
> The grouping API I'm suggesting offers an nicer alternative to the (FG)AM approach that would also work over HotRod. ATM there's no TX support for HotRod so it seems like to be able to support the HotRod and OGM integration fully, we'd need HR transactions as well. Do you think the integration can be done in steps: 
> 1. add grouping over hotrod and integrate with OGM
> 2. add tx and make the integration use it
> 
> Or we should wait till 2. and then proceed with the integration?

We can / should to it in two steps as long as we mark it as toy / non data safe in the documentation until step 2 is done.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140122/a54388cc/attachment-0001.html