Please, anyone can submit an example of async call to orientdb from verticle (vert.x)
Thank you!! El sábado, 30 de mayo de 2015, 10:38:34 (UTC+2), Mohammad Naghavi escribió: > > Hi again, > ok thanks, that seems clear now. > > Regards, > > From: Luigi Dell'Aquila <[email protected]> <javascript:> > Reply: [email protected] <javascript:> > <[email protected]>> <javascript:> > Date: 29 May 2015 at 12:23:44 > To: [email protected] <javascript:> > <[email protected]>> <javascript:> > Subject: Re: [orientdb] Re: async, non blocking java API > > Hi Mohammad, > > TinkerPop API is designed for synchronous communication, and OrientDB API > is compliant with this behavior. > If you need asynchronous communication I suggest you to use SQL and > commands > > Regards > > Luigi > > > 2015-05-29 11:31 GMT+02:00 Mohammad Naghavi <[email protected] > <javascript:>>: > >> Hi Luigi, >> >> I'm using the Graph API for Java mostly the Tinkerpop compliant parts due >> to some advantages it has for me. My question was, is there a way to make >> the parts of that API that need communication with DB as non-blocking or >> should I switch all my DB interaction code to use SQL instead? >> >> regards, >> Mohammad >> >> On Friday, May 29, 2015 at 11:04:50 AM UTC+2, Luigi Dell'Aquila wrote: >>> >>> Hi Mohammad, >>> >>> What do you exactly mean? Non blocking queries can be used to query both >>> documents and graphs, non blocking commands can be executed on both >>> ODatabaseDocument and OrientGraph and you can execute graph queries out of >>> the box on both. >>> In addition, you can always convert documents do vertices/edges with >>> graph.getVertex(doc) >>> >>> Luigi >>> >>> >>> 2015-05-27 10:27 GMT+02:00 Mohammad Naghavi <[email protected]>: >>> >>>> so I want to ask more details on this issue. As I have seen on >>>> documentation as well as on the github issue, there is a non-blocking API >>>> for document API planned, but is there something similar planned for the >>>> graph API? does it actually make sense? >>>> The reason I ask is that I'm using graph API and we specially benefit >>>> from a lot of automatic work done in background when we use it. Like >>>> bidirectional links, nested transactions and so on. so it will be a hard >>>> and very time consuming change to switch to document API to improve >>>> performance with non-blocking document API. >>>> >>>> >>>> On Wednesday, October 1, 2014 at 5:03:49 PM UTC+2, Carlo Pradissitto >>>> wrote: >>>>> >>>>> Hi all, >>>>> since our architecture is heavily based on non-blocking services, both >>>>> at the nginx level and (especially) at the vert.x level, we think that >>>>> using the blocking ODB APIs might lead to a scalability bottleneck. >>>>> As Jackub Liska has underlined, nowadays many frameworks are based on >>>>> event-loop rather than a more traditional thread pool logic. >>>>> >>>>> We'd appreciate a lot to know whether this issue >>>>> <https://github.com/orientechnologies/orientdb/issues/2173> is going >>>>> to be assigned to a milestone or rejected, so that we can arrange our >>>>> development schedule accordingly. >>>>> >>>>> Regards, >>>>> Carlo >>>>> >>>>> >>>>> >>>>> Il giorno mercoledì 7 maggio 2014 20:40:52 UTC+2, Sébastien Deleuze ha >>>>> scritto: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> An executor with a dedicated thread pool will be still blocking, the >>>>>> only advantage is that the thread is in a separate thread pool. >>>>>> >>>>>> The whole purpose of a real asynchronous non blocking implementation >>>>>> is to have no thread waiting for the database response. >>>>>> All systems can handle a limited number of simultaneous threads, so >>>>>> this kind of model greatly improves scalability. >>>>>> Since implementation is not obvious, most http or persistence >>>>>> libraries use Netty or equivalent to implement it. >>>>>> >>>>>> You can have a look at Mongo Java Driver 3.0-SNAPSHOT async-driver as >>>>>> an example of NoSQL driver implementing this kind of needs. >>>>>> https://github.com/mongodb/mongo-java-driver/tree/3.0.x >>>>>> >>>>>> Historically this kind of architecture has been more popular in Scala >>>>>> ecosystem, because of their nice Promise API. >>>>>> Hopefully, Java 8 now comes with lambdas (great for specifying >>>>>> callbacks) and the great CompletableFuture. >>>>>> CompletableFuture is non blocking compliant since it allows to >>>>>> specify a callback that will be called later, >>>>>> unlike Java 5 Future which can only produce async blocking API. >>>>>> >>>>>> Since most NoSql drivers do not depend on Java 8, most of them >>>>>> implement their own CompletableFuture equivalent. >>>>>> For example >>>>>> https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/MongoFuture.java >>>>>> >>>>>> These equivalents allow to use lambdas since they implement a >>>>>> functional interface (interface with one method). >>>>>> >>>>>> @Luca, as I told you a few months ago, my initial plan was to use >>>>>> OrientDB for OpenSnap implementation >>>>>> (a SnapChat clone based on Java 8, Spring 4 and AngularDart) but I >>>>>> had to fallback on MongoDB since it >>>>>> provides such support. I would be really happy to migrate it to >>>>>> OrientDB when it will be available. >>>>>> >>>>>> You can have a look to OpenSnap source code ( >>>>>> https://github.com/sdeleuze/opensnap) in order to have a look >>>>>> to what a full asynchronous non blocking app based on Spring looks >>>>>> like. >>>>>> >>>>>> Such feature would be a huge enabler to switch on OrientDB !!! >>>>>> >>>>>> Regards, >>>>>> Sébastien >>>>>> >>>>>> Le jeudi 1 mai 2014 07:42:37 UTC+2, Leng Sheng Hong a écrit : >>>>>>> >>>>>>> this will be extremely useful as I am too using vertx async >>>>>>> framework. +1 >>>>>>> >>>>>>> On Wednesday, 19 March 2014 23:57:47 UTC+8, sANTo L wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Do you provide an async, non blocking java API for OrientDB and if >>>>>>>> not, are there any plans to provide it in the near future ? >>>>>>>> The reason I ask this is because I'm writing a java web application >>>>>>>> based on the Vert.x platform. >>>>>>>> In Vert.x it's required that you don't have any blocking code and >>>>>>>> therefore I'm interested in a database with which my application can >>>>>>>> interact in an async, non blocking way. >>>>>>>> >>>>>>>> regards, >>>>>>>> >>>>>>>> Santo >>>>>>>> >>>>>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "OrientDB" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "OrientDB" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/orient-database/MBQJmUNV7bA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
