3

I was learning and using reactive streams programming with akka streams, I was trying to find any libraries for an async-jdbc-driver or reactive-jdbc-driver for 2 years, and I found slick 3.0 or rxjava-jdbc-driver provide async jdbc api, but I know slick is building the amazing api on top of JDBC api, which is blocking (correct me if I am wrong), so I guess from system perspective, it may not be 100% reactive system from top to bottom.

Another amazing event was that last year 'Reactive Streams Specification V1.0' was released, so my questions are:

  1. Will the event trigger JDBC Expert Group to design async JDBC API support?
  2. And then Database Provider Organizations, such as MySQL's provider Oracle, is there any plan to implement corresponding drivers?
  3. If this is hopeless, any directions or replacement or anything I could turn into or JDBC layer does not have to be reactive and scale-out mysql servers is good enough?
Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
Barry Zhong
  • 470
  • 3
  • 17
  • There are no such plans at this time. JDBC is pretty low-level, and it is more likely that a framework will emerge that will build reactive-like behavior around a JDBC driver. – Mark Rotteveel Apr 24 '16 at 08:43

2 Answers2

2

I'm not aware of any plans either. Many NoSQL solutions, who are not bound by the old JDBC API, started providing reactive-based APIs. Whether or not those are full stack reactive I can't say; you should confirm that by looking at their spec/implementation.

As we have full stack reactive solutions for TCP/HTTP via RxNetty (Retrofit, OkHttp?) and there are movements for Servlet 4.0 as well, it would be great we could just compose over an async JDBC source. However, that requires a new API design from ground up.

Perhaps once JDK 9 and is Flow API (which is essentially Reactive-Streams but under a different package) is understood and embraced among the JDK developers. Note though that it is likely the plain Reactive-Streams API might not be completely adequate for such I/O and a more expanded API is required in the form of bidirectional reactive streams.

Maybe someone with JEP experience could pick up the issue and we can start iterating on the approaches.

Until then, we have the blocking wrappers around JDBC you mentioned.

akarnokd
  • 69,132
  • 14
  • 157
  • 192
  • I found a tech talk at scala days 2015 "Reactive Slick for Database Programming" by Slick project lead Stephan Zeiger https://www.youtube.com/watch?v=WvxXz7aklik I might be wrong, but I think basically he mentioned atm they are working on native database driver, and for now setup different threadpools to different connction pools according to different datasources and with Slick3 might be the way out. With back-pressure technology, slick will not load data from db while client is not ready to process, so application performance is somehow optimized. Correct me if I was wrong. – Barry Zhong Apr 26 '16 at 11:49
1

According to Oracle, they are in the work of providing a non blocking API for JDBC.

As stated in the link:

This new API is completely nonblocking. It is not intended to be an extension to, or a replacement for, JDBC but, rather, an entirely separate API that provides completely nonblocking access to the same databases as JDBC.

You can now download the new API from OpenJDK and get involved with the project by reviewing the API and providing feedback on the JDBC mailing list

dazito
  • 7,740
  • 15
  • 75
  • 117