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.

Reply via email to