Hi again, ok thanks, that seems clear now. Regards,
From: Luigi Dell'Aquila <[email protected]> Reply: [email protected] <[email protected]>> Date: 29 May 2015 at 12:23:44 To: [email protected] <[email protected]>> 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]>: 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 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 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]. 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.
