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