Async Programming in Java Repositories
Java is an object-oriented language; it supports encapsulation, inheritance and polymorphism. As we can see from Java’s continuing success in enterprise applications after 30 years, this is a popular way to develop applications that include lots of business logic. Much of this business logic requires accessing and processing data stored in a persistent form, typically (although not exclusively) in a database.
Relational databases, which are probably the most common way of storing large amounts of data, do not easily map to an object-oriented approach. This is referred to as the object-relational impedance mismatch.
Over the years, various approaches have been employed to address this issue. Entity EJBs were an early solution that never gained much traction. Other frameworks, such as Hibernate and the Java Persistence API, have proven much more popular.
At a more basic level, design patterns can be used to simplify this type of coding. Data Access Objects (DAO) is one, and the Repository pattern is another.
In this article, we will look at the Repository pattern and, specifically, how this can be used asynchronously.
Before we get into the details, let’s discuss what asynchronous means in this context.
Understanding Synchronous vs. Asynchronous Execution
When a result is needed in an application, we make a call to something that will provide that result. That could use anything from a Java method to a RESTful web service request across a network. The result will take time to produce, and we have two choices about how to deal with this. The first is to make the call synchronous; we make the request and wait for the result to be returned. This will block our application thread from doing any more work until the result is returned.
The second option is to make the call asynchronously. In this case, we make the request but don’t wait for the result to be returned. We are free to continue doing useful work that does not depend on the result.
Why Use Async in Java Repositories?
One example of where this would be particularly useful is if you need to query several different sources that will not respond immediately. Using an asynchronous approach, the time taken to deliver all the results will be that of the slowest source to respond, rather than the total of the time required by each source.
Like all good patterns, the Repository design pattern is simple to describe (one of the key goals of patterns is to provide a shared vocabulary for developers). It also uses the most common way of solving problems in software development: it introduces another level of abstraction.
Understanding the Repository Pattern
Interacting with data sources will require different (potentially complex) protocols, depending on the source and its implementation. If we integrate these protocols directly into our business logic, we are making our code very brittle. Any changes to the source we want to use or how we interact with it require changes to our code.
To eliminate this, we introduce a repository; you can think of this as being analogous to a librarian. When you need data (a book), the librarian knows where it is and how to access it. If you need a different book, you simply ask the librarian who visits the new location. This is a specialised form of the façade pattern.
The repository abstracts how we interact with a data source, providing the most common forms of operation: create, read, update and delete. As a user of the repository, we do not concern ourselves with how these functions are implemented; whether a JDBC call is required, or a RESTful web service call does not concern us. Should we need to change to an alternative data store, using a different protocol, this can be handled in isolation by changing the repository implementation. The business logic of our application, using the basic operations, will not require any changes.
Implementing Async Methods in Java Repositories
This approach can also simplify how we make our calls asynchronous. A call to the repository can return immediately. Because we need to know when the operation has been completed, we will register a callback handler with the repository. We can start multiple operations, and as they are completed, the handlers are called, and we can track our progress. This also gives us greater flexibility over handling operations that fail or take too long to complete.
Java has a rich set of libraries, making implementing an asynchronous repository easier. The introduction of the CompletableFuture class in JDK 8, which supports multiple stages, is particularly useful. In addition, the repository pattern can make excellent use of Virtual Threads (introduced in JDK 21) to deliver significantly increased scalability when used in the prevalent thread-per-request design.
Key Takeaways for Async Java Repository Implementation
In summary, the repository pattern provides a way to make business logic both more readable and maintainable. The potential downside is an additional layer of abstraction that could degrade overall performance. This downside can be minimised when combined with asynchronous operations that take advantage of Java’s Virtual Threads.
There are many ways to design applications that need access to data sources; the asynchronous repository should be considered a powerful tool when choosing the right approach for your application.
