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]>: > 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]. > 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.
