Announced at the SpringOne Platform conference in Washington DC, R2DBC is an experimental API designed from the ground up for Reactive programming against relational databases. The end goal is try to influence the Asynchronous Database Access (ADBA) specification.
Speaking at the event, Ben Hale, Cloud Foundry Java Experience Lead, stated that R2DBC is designed around four design principles:
- Utilize Reactive Streams Types and Patterns.
- Be completely non-blocking, all the way to the database.
- Shrink the driver SPI to the minimal set of operations that are implementation specific, regardless of usability.
- Enable multiple "humane" APIs to be built on top of the driver SPI.
This is an example from Hale's presentation of a simple Select statement:
The connectionFactory.create() returns a Mono of a connection. Hale explained that the net result of this invocation is that "at the end, when somebody subscribes, it goes and grabs a connection, executes the query, and then for each one of those rows returns the value, say an integer, resulting in a Flux of integers as the end result, with a lifecycle around the connection that is only opened on subscribe and closed off once it is complete."
Of course, a client built on top of the SPI can further simplify this, and Hale showed such an example where the details are hidden away:
This is what a Prepared Insert looks like inside a transaction using the SPI:
As Hale admitted during his presentation, this isn’t great, but again it can be simplified at the client:
There are some alternatives to R2DBC. One is to wrap JDBC in a thread pool, but this doesn’t offer back pressure - unbounded queues will lead to resource exhaustion, and bounded queues lead to blocking. The other is ADBA. Speaking carefully, Hale said that:
We engaged pretty early with the ADBA crew, but there is a lot of contention around whether CompletableFuture is actually Reactive so we disengaged which led to our R2DBC effort. But now that are R2DBC effort has actual proof and working APIs we are being invited back to engage again. So ADBA might actually become this, and to some extent that is the end goal of a project like this.
In terms of future plans, Hale made it clear that R2DBC is an experimental playground, and whilst it is stable enough to play with, it absolutely is not intended for production use. It is important to note that there are a number of edge cases, including a lack of BLOB/CLOB handling, and at the time of writing only one database - PostgreSQL - is supported, but Hale is keen to see implementations for other databases. He ended by saying:
Spring doesn’t generate specs. We aren’t spec leads and we don’t host specifications. This project's entire goal is a way to influence the ADBA spec, and that is the best possible scenario. But make no mistake, I am not the sort of person who is going to tolerate the ADBA spec being bad. If they don’t take our advice, if they don’t see that Reactive is different from being async, then this is something that the Spring team will do.
InfoQ is filming all the sessions at SpringOne again this year, and all videos will be made available on the site over the coming months. To receive notifications as the sessions are published, follow the SpringOne Platform 2018 topic.