Is it possible to use Hibernate and RDBMS(Mysql, Postgres etc) with ReactiveCrudRepository
instead of CrudRepository
? I have tried some samples with Spring Data Jpa and Hibernate, but couldn't get it done. I was only able to find a few samples on ReactiveCrudRepository
for MongoDB and cassandra.
Is it possible to use Hibernate and Mysql with
ReactiveCrudRepository
instead ofCrudRepository
?
Not with Hibernate and MySQL, but with R2DBC and Postgres, Microsoft SQL Server or H2. Take a look at Spring Data R2DBC.
With Hibernate/JPA included this won't happen in the foreseeable future. JPA is based on the idea that you load part of your data model into memory, manipulate the resulting object model and let JPA transform these changes. All this within a single transaction.
This is kind of the opposite how one deals with a reactive store where you try to make atomic changes and try to decouple the loading, processing and storing and all this without blocking.
So we have to look at the technology level below JPA: JDBC. But JDBC is still blocking: You send a SQL statement to your database and then JDBC will block until you get the result. And again this goes against the idea of reactive: Never block. One could wrap this in a thread pool to mitigate this to some extent, but that is more of a workaround than a solution.
There are some suitable drivers for some databases that could be used for reactive repositories. But they are proprietary and thereby not a good basis for something that really should eventually work across all (relevant) relational databases.
For some time the Spring Data team hoped that ADBA would fill that gap. But discussions on the mailing list made it clear that ADBA was not aiming for reactive but only for asynchronous. Again not what we needed for a reactive repository abstraction.
So early in 2018 various people living at the intersection or reactive and relational decided that we need a standard for reactive database access.
R2DBC (Reactive Relational Database Access) is a proposal for such a standard. The hope is that it either helps convincing Oracle to move ADBA to a reactive approach or if that doesn't happen it becomes the standard itself.
And with already three implementations available chances for the second option look promising.
R2DBC itself is mainly an SPI, i.e. an API that is to be implemented by database providers. The SPI is designed in a way that puts minimal requirements on implementers. But this also makes R2DBC somewhat cumbersome to use. The idea is that other libraries will step up and build libraries designed for usability on top of that SPI, as it happened with JDBC.
Spring Data R2DBC is one such library and it offers what you asked for: Support for ReactiveCrudRepository
although it is independent of JPA/Hibernate and there is no support for MySQL yet.
Both R2DBC and Spring Data R2DBC didn't have a production release yet and it will take at least several months to get there.
Spring Data R2DBC just released the first milestone. See the release article for its current capabilities.
R2DBC is on its 6th milestone. See the release article for details.
See also this answer: Why does Spring not provide reactive (non-blocking) clients for relational databases?
As of now (Jan 2017) it is not possible.
The currently relevant release for the reactive part of Spring Data is Spring Data Kay M1 (You can check if there is a newer version available on the project home page)
And a blog post from the Spring Data team about that release and specifically the reactive parts in it starts with (emphasis mine):
Spring Data Kay M1 is the first release ever that comes with support for reactive data access. Its initial set of supported stores — MongoDB, Apache Cassandra, and Redis — all ship reactive drivers already, which made them very natural candidates for such a prototype.
The reason is that there is no standard non-blocking way to access a relational database. So only those that support this kind of API are supported right now.
One could implement a ReactiveCrudRepository
using JPA or JDBC and delegate the work to a thread pool. This would provide an async API on the outside, but would still consume the resources for the Threads and block between independent data accesses, so only a small part of the benefits of the reactive approach would get realized.