On Tue, Jan 21, 2014 at 4:07 PM, Mircea Markus <mmar...@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. > > 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 <mmar...@redhat.com> wrote: > > > > > On Nov 19, 2013, at 10:22 AM, Emmanuel Bernard <emman...@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 <emman...@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 <emman...@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@lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>>>>> > >>>>>> _______________________________________________ > >>>>>> infinispan-dev mailing list > >>>>>> infinispan-dev@lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>>>> _______________________________________________ > >>>>> infinispan-dev mailing list > >>>>> infinispan-dev@lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >>>> _______________________________________________ > >>>> infinispan-dev mailing list > >>>> infinispan-dev@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@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >> _______________________________________________ > >> infinispan-dev mailing list > >> infinispan-dev@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev