When transitioning from traditional monolithic applications or modular architectures to a microservices-based approach, several things change in how the system behaves, particularly in terms of database access. While microservices promise greater flexibility and scalability, they also introduce challenges that might not have been as pronounced in monolithic applications.

In a typical monolithic application, the flow of data is often linear, with fewer HTTP requests and more centralized logic. However, in a microservices architecture, the number of HTTP requests increases significantly due to the distributed nature of the services. This, in turn, places a heavier load on database connections and can overwhelm connection pools, particularly those managed by HikariCP, which is commonly used in Spring applications.

At first, everything seems to run smoothly, but as your microservices grow and the number of HTTP requests increases, you may start to encounter inexplicable bugs that are difficult to trace. The root of these issues often lies in improper session or database connection management. It’s easy to make the mistake of holding onto Hibernate sessions longer than necessary, especially when threads are reading files or performing non-database-related processing.

This article explores one such aspect of microservices architecture — proper management of Hibernate sessions and database connections — and how approaches like Open Session in View (OSIV) can help address some of the challenges introduced in distributed systems. As you develop your microservices, you’ll need to adopt more careful and deliberate strategies to ensure that your Hibernate sessions aren’t unnecessarily monopolizing database resources while the system is performing other tasks. Let’s dive into the details and see how this impacts performance and stability.

What is OSIV?

Open Session in View (OSIV) is a pattern commonly used with Hibernate and Spring to manage database sessions in the context of a web request. The main idea behind OSIV is to keep the Hibernate session open during the entire lifecycle of a web request, ensuring that entities can be lazily loaded even after the initial database transaction has been completed.

How OSIV Works

In Spring applications, especially those using Hibernate as the persistence framework, database access is often done in the form of transactions. The transaction starts when a request comes in and is committed or rolled back when the response is sent out. In a typical non-OSIV setup, the session is closed as soon as the transaction is committed. This means any lazy-loaded collections or properties would throw exceptions if accessed after the session is closed.

With OSIV enabled, the Hibernate session remains open throughout the entire lifecycle of the HTTP request. This allows the lazy loading of entities during the rendering of the view, even after the transactional boundaries are closed. Essentially, OSIV “opens” the session and keeps it open until the HTTP response is fully rendered.

Key Components Involved in OSIV

1. The OSIVSessionFilter plays a crucial role in keeping the Hibernate session open during the entire HTTP request lifecycle. When OSIV is enabled, this filter ensures that the session is not closed after the transaction has ended but instead remains open for lazy loading during view rendering. This aligns directly with the behavior described above, where the session stays active beyond the transaction’s lifecycle.

2. The Hibernate session is responsible for interacting with the database. In a typical non-OSIV scenario, the session is closed immediately after the transaction is committed, limiting access to any lazily loaded properties. However, with OSIV, the session is kept open and remains active throughout the entire HTTP request lifecycle, enabling lazy loading to occur even during the view rendering phase, after the transaction’s scope ends.

3. The DispatcherServlet manages the entire request-response cycle in Spring MVC applications. In the context of OSIV, it ensures that the request is processed correctly by integrating with the OSIVSessionFilter. The filter binds the session to the current thread during the entire request lifecycle, allowing the session to stay open during the rendering phase and enabling lazy loading. The DispatcherServlet ensures that once the view rendering is complete and the response is sent, the session is properly closed.

By understanding the interplay between the OSIVSessionFilter, Session, and DispatcherServlet, we can see how OSIV allows for lazy loading of data even after the transaction ends, making it possible to access entities in the view rendering phase without encountering session-related exceptions.

Key Benefits of OSIV

Lazy Loading in Views

The most obvious benefit is that it allows lazy loading of associations (like collections or referenced entities) while rendering the view. Without OSIV, such entities may not be accessible after the transaction is closed, but with OSIV, they remain available.

Simplified Code

OSIV can simplify the code in some cases because developers don’t need to explicitly manage session opening and closing within the service layer. The session is kept open for the entire duration of the request, making it more straightforward to work with.

Reduced Complexity

By allowing lazy-loaded properties to be accessed during the view rendering phase, OSIV reduces the need to eagerly fetch data in advance, which might improve performance by not over-fetching data.

Potential Drawbacks of OSIV

While OSIV can be useful, it also has its drawbacks, and it should be used judiciously:

Performance Issues

Keeping the session open for the entire lifecycle of the request can lead to performance issues, especially in high-load systems. The session can accumulate unnecessary objects in memory, leading to potential memory leaks or excessive database queries.

Hidden Database Queries

One of the main concerns with OSIV is that it can lead to N+1 select problems. Because the session is kept open throughout the request, Hibernate may lazily load collections or properties when the view is rendered, potentially resulting in multiple queries being issued when only one was expected.

Transactional Boundaries

OSIV can also blur transactional boundaries. For example, if an exception occurs during the view rendering phase, the session remains open and may unintentionally commit or roll back part of a transaction that wasn’t intended.

When Should OSIV Be Used?

OSIV is most beneficial in scenarios where:

• You are working with complex entity graphs and need to lazy-load associated data during the rendering of the view.
• You need to avoid eager fetching strategies that could result in performance degradation by retrieving too much data upfront.

When Should OSIV Be Avoided?

However, there are cases where OSIV should be avoided, including:

• When the risk of N+1 query problems is high, and you have a lot of associations that could be lazily loaded.
• When you need clear transactional boundaries, as keeping the session open during the view rendering phase can make it difficult to manage database transactions explicitly.

How to Enable OSIV in Spring

Enabling OSIV in a Spring application is easy. You just need to configure it in your application.properties file or application.yml.

For Spring Boot, add the following to your application.properties:

spring.jpa.open-in-view=true

Conclusion

OSIV is a useful feature in Spring applications to manage database sessions and enable lazy loading of entities during view rendering. However, developers should be cautious when using it because it can lead to performance problems like N+1 query issues.

When to use OSIV:

• For complex entity graphs and situations where lazy loading is needed during view rendering.
• When eager fetching strategies would result in excessive data fetching and degraded performance.

When to avoid OSIV:

• When there’s a high risk of N+1 queries and too many associations are lazily loaded.
• When you need clear transactional boundaries, as OSIV can blur the lines of transaction management.

Best Practices:

• Use JOIN FETCH to eagerly load collections and avoid the N+1 problem.
• Be mindful of performance and transaction boundaries when deciding whether to enable OSIV.

By understanding these nuances, you can ensure that your application benefits from OSIV without introducing unexpected performance issues.