[infinispan-dev] Integration between HotRod and OGM

Wed Jan 22 09:05:15 EST 2014


Sent from my iPhone

> On 22 Jan 2014, at 13:58, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> 
> 
> 
>> On Tue, Jan 21, 2014 at 4:07 PM, Mircea Markus <mmarkus at redhat.com> wrote:
>> Hi Emmanuel,
>> 
>> Just had a good chat with Davide on this and one solution to overcome the shortcoming you mentioned in the above email would be to enhance the hotrod client to support grouping:
>> 
>> RemoteClient.put(G g, K k, V v); //first param is the group
>> RemoteClinet.getGroup(G g) : Map<K,V>;
> 
> I think you'd also need RemoteClient.get(G g, K k), as in embedded mode the group is included in the key.

Yes

> 
>  
>> 
>> It requires an enhancement on our local grouping API: EmbeddedCache.getGroup(G). This is something useful for us in a broader context, as it is the step needed to be able to deprecated AtomicMaps and get suggest them being replaced with Grouping.
> 
> It would also require us to keep a Set<K> for each group, with the keys associated with that group. As such, I'm not sure it would be a lot easier to implement (correctly) than FineGrainedAtomicMap.
> 
>> 
>> This approach still has some limitations compared to the current embedded integration:
>> - performance caused by the lack of transactions: this means increased TCP chattiness between the Hot Rod client and the server.
>> - you'd have to handle atomicity, potentially by retrying an operation
>> 
>> What do you think?
>> 
>> 
>> On Dec 3, 2013, at 3:10 AM, Mircea Markus <mmarkus at redhat.com> wrote:
>> 
>> >
>> > On Nov 19, 2013, at 10:22 AM, Emmanuel Bernard <emmanuel at hibernate.org> 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.
>> >
>> > The Java Hotrod client is both multithreaded and exposes an Async API.
>> >
>> >>
>> >> 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.
>> >
>> > I think so too :-)
>> >
>> >> 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
>> >
>> > Cheers,
>> > --
>> > Mircea Markus
>> > Infinispan lead (www.infinispan.org)
>> >
>> >
>> >
>> >
>> 
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140122/5f4d5a98/attachment.html