Spring Framework announced recently to ship with support for reactive transaction management.
Let’s take an in-depth look at how this works for R2DBC, the reactive specification for SQL database access.

R2DBC Tour took place in Mid- and North-parts of Germany. R2DBC standardizes reactive integrations with SQL databases as Open Source initiative.

Reactive Relational Database Connectivity (R2DBC) started out as idea to see what’s possible when thinking about reactive programming and SQL databases. Since the last months, R2DBC grew beyond that idea. It inspired driver maintainers and client library authors as common language: A specification for drivers and an interface for library authors so they can build client libraries on top of a vendor-independent SPI. Client libraries are tools that we as application developers need to keep productivity high and not to solve problems that are solved already.

Last year I announced the R2DBC Java User Group and recently I started the tour visiting various user groups and conferences. Reactive Relational Database Connectivity lifts a roadblock when integrating with SQL databases. It’s an Open Source standardized API across multiple database drivers and an ongoing specification effort hosted on GitHub.

Imperative code eats threads at the pace of incoming requests while Software is eating the world. This post discusses the assumptions for reactive programming on the JVM and what this means for integrations – in particular, relational databases.

The motivation to come up with a post is the constant increase in reactive programming adoption while some major building blocks are not yet available – in particular, the question: What about relational databases?