[infinispan-dev] Integration between HotRod and OGM

[Emmanuel Bernard]

This message was a response to a different email discussing the composite
key approach "k1 - a1" "k1 - a2".

The actual JIRAs are opened :

* https://issues.jboss.org/browse/ISPN-3732
* https://issues.jboss.org/browse/ISPN-3733

Emmanuel

On Tue 2013-11-19 11:22, Emmanuel Bernard wrote:
> It's an interesting approach that would work fine-ish for entities
> assuming the Hot Rod client is multi threaded and assuming the client
> uses Future to parallelize the calls.
> 
> But it won't work for associations as we have them designed today.
> Each association - or more precisely the query results to go from an
> entity A1 to the list of entities B associated to it - is represented by
> an AtomicMap.
> Each entry in this map does correspond to an entry in the association.
> 
> While we can "guess" the column names and build from the metadata the
> list of composed keys for entities, we cannot do the same for
> associations as the key is literally the (composite) id of the
> association and we cannot guess that most of the time (we can in very
> pathological cases).
> We could imagine that we list the association row keys in a special
> entry to work around that but this approach is just as problematic and
> is conceptually the same.
> The only solution would be to lock the whole association for each
> operation and I guess impose some versioning / optimistic lock.
> 
> That is not a pattern that scales sufficiently from my experience.
> That's the problem with interconnected data :)
> 
> Emmanuel
> 
> On Mon 2013-11-18 23:05, Mircea Markus wrote:
> > Neither the grouping API nor the AtomicMap work over hotrod.
> > Between the grouping API and AtomicMap, I think the one that would make more sense migrating is the grouping API.
> > One way or the other, I think the hotrod protocol would require an enhancement - mind raising a JIRA for that?
> > For now I guess you can sacrifice performance and always sending the entire object across on every update instead of only the deltas?
> > 
> > On Nov 18, 2013, at 9:56 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > 
> > > Someone mentioned the grouping API as some sort of alternative to
> > > AtomicMap. Maybe we should use that?
> > > Note that if we don't have a fine-grained approach we will need to
> > > make sure we *copy* the complex data structure upon reads to mimic
> > > proper transaction isolation.
> > > 
> > > On Tue 2013-11-12 15:14, Sanne Grinovero wrote:
> > >> On 12 November 2013 14:54, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > >>> On the transaction side, we can start without them.
> > >> 
> > >> +1 on omitting transactions for now.
> > >> 
> > >> And on the missing AtomicMaps, I hope the Infinispan will want to implement it?
> > >> Would be good to eventually converge on similar featuresets on remote
> > >> vs embedded APIs.
> > >> 
> > >> I know the embedded version relies on batching/transactions, but I
> > >> guess we could obtain a similar effect with some ad-hoc commands in
> > >> Hot Rod?
> > >> 
> > >> Sanne
> > >> 
> > >>> 
> > >>> On Tue 2013-11-12 14:34, Davide D'Alto wrote:
> > >>>> Hi,
> > >>>> I'm working on the integration between HotRod and OGM.
> > >>>> 
> > >>>> We already have a dialect for Inifinispan and I'm trying to follow the same
> > >>>> logic.
> > >>>> At the moment I'm having two problems:
> > >>>> 
> > >>>> 1) In the Infinispan dialect we are using the AtomicMap and the
> > >>>> AtomicMapLookup but this classes don't work with the RemoteCache. Is there
> > >>>> an equivalent for HotRod?
> > >>>> 
> > >>>> 2) As far as I know HotRod does not support transactions. I've found a link
> > >>>> to a branch on Mircea repository:
> > >>>> https://github.com/mmarkus/ops_over_hotrod/wiki/Usage-guide
> > >>>> Is this something I could/should use?
> > >>>> 
> > >>>> Any help is appreciated.
> > >>>> 
> > >>>> Thanks,
> > >>>> Davide
> > >>> 
> > >>>> _______________________________________________
> > >>>> 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
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > infinispan-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > 
> > 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