Reactive Systems in Java

Chapter 9. Accessing Data Reactively

In Chapter 5, we explained the scalability and robustness problems in the use of blocking I/O for applications. This chapter focuses on interacting with databases and how Quarkus ensures that the data layers of an application stack can be asynchronous and utilize nonblocking I/O too.

The Problem with Data Access

Accessing relational data previously involved blocking I/O while communicating with a database. As already discussed in Chapter 5, we want to avoid blocking I/O in our applications, at any level of the stack. Interacting with a database often takes a non-trivial amount of time to complete, depending on the number of records involved, creating an even larger impact on our application with blocking I/O to access a database! What do we mean by this? Let’s say we’ve developed a small database application; we’ve all developed many of those over the years. We often refer to them as CRUD applications because they provide create, read, update, and delete operations for records in a database.

Every exposed endpoint in our API needs to interact with the database. We will ignore caches and how they reduce the number of requests made to a database in certain situations. With each endpoint method calling the database, every execution performs blocking I/O, reducing concurrency.

Why are we forced to use blocking I/O when interacting with databases? APIs for interacting with databases, such as Open Database Connectivity (ODBC) and Java Database Connectivity ...