On 22 Jan 2014, at 14:48, Mircea Markus <mmar...@redhat.com> wrote: > > On Jan 22, 2014, at 1:26 PM, Emmanuel Bernard <emman...@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.
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
