Using Ebean with Vert.x - blocking or non-blocking?

339 views
Skip to first unread message

Ratnadeep Rakshit

unread,
Apr 21, 2018, 6:40:45 PM4/21/18
to Ebean ORM
I am planning to use Ebean with vert.x for my latest project. However I wanted to know if Ebean has an Async api? Although vert.x allows blocking operations on worker threads, I am looking for a pure async solution. Has anyone worked with Ebean and Vert.x before?

Rob Bygrave

unread,
Apr 23, 2018, 6:54:36 AM4/23/18
to ebean@googlegroups
However I wanted to know if Ebean has an Async api? 

Not really.  It has "future" query execution like findFutureList(), findFutureCount(), findFutureIds(). 



> I am looking for a pure async solution

Well in my opinion how much "joy" you get pursuing a pure async solution will depend on the DB you are talking to and the underlying architecture of that DB.

JDBC today is a blocking API. I believe it will stay that way for a long long time yet. 

Today generally speaking a JDBC connection could be described as being "backed/supported" on the DB side by a "shadow process". I would argue that in general that database "shadow process" is a significantly more important resource than a application side thread and until that fundamentally changes the desire for "pure async solution" stops when we get to the JDBC Connection.

That is, any thread that holds a JDBC connection by proxy maps to our very important database "shadow process" and generally we should keep that thread focused on it's task of processing JDBC input or output and not context switching.

Ebean functions mostly operate with a JDBC Connection and so operate in a blocking non-async way and I don't see that changing anytime soon.







On 22 April 2018 at 10:40, Ratnadeep Rakshit <qed...@gmail.com> wrote:
I am planning to use Ebean with vert.x for my latest project. However I wanted to know if Ebean has an Async api? Although vert.x allows blocking operations on worker threads, I am looking for a pure async solution. Has anyone worked with Ebean and Vert.x before?

--

---
You received this message because you are subscribed to the Google Groups "Ebean ORM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ebean+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark Paluch

unread,
May 18, 2019, 6:43:09 AM5/18/19
to Ebean ORM
Hi Rob, 

skimming through ebean's mailing list I found this thread. Wanted to leave my 2ct here:

There are several initiatives to bring a standardized API for non-blocking SQL database access:

* vert.x
* Oracle's ADBA
* R2DBC

Each of these is quite young and there's somewhat uncertainty which API is going to be a widely accepted standard.

Right now, vert.x has a Postgres driver implementation, ADBA is source-code only without a proper implementation (well, ADBA over JDBC) and R2DBC has drivers available for MySQL, Postgres, H2, SQL Server, Google Cloud Spanner (more to come) with the ability to wrap less-capable non-blocking implementations.

Let me know if you'd like to continue on this thread.

Cheers, 
Mark
To unsubscribe from this group and stop receiving emails from it, send an email to eb...@googlegroups.com.

Rob Bygrave

unread,
May 22, 2019, 7:44:35 AM5/22/19
to ebean@googlegroups
Hi,

Yes, I'm watching several github repos for async drivers myself.  By all means add to the thread.

Cheers, Rob.




To unsubscribe from this group and stop receiving emails from it, send an email to ebean+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ebean/7e9a8579-4783-4421-bb85-a360194ba058%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages