Spring Boot & OSIV
The dreaded Open-Session-In-View, or OSIV, is a software design pattern that aims to simplify the communication between a web application’s persistence layer and a database. This communication is usually achieved by utilising the concept of a Session that ORM providers use to maintain a connection with said database.
In a nutshell, OSIV works by initiating the Sessions while still in the view layer, considering a multi-tier web application. This means that the Session is created proactively upon receiving an HTTP request. It'll be reused if needed and will be closed at the very end of request processing, just prior to sending the response. As one may imagine, this is a relatively ambitious take on Session management as Sessions are traditionally only created on demand, if and when they're actually needed. This usually occurs in the service layer of an application where the business logic that needs the database lives.
There's a plethora of discussions on the internet in relation to OSIV, varying in technical depth. Proponents of the OSIV way claim that it boosts developer productivity by obscuring “low-level” technical details such as database communication overhead, allowing for a better focus on the business logic at hand. As it turns out, however, most developers are not in favour of using it and consider it an anti-pattern. The reasoning is that OSIV-backed apps may exhibit performance issues that are very hard to troubleshoot, because of the implicit treatment of Sessions. This is especially common for complex apps with loads of data, which makes OSIV a poor choice when considering scale. Furthermore, since OSIV may perform database transactions implicitly, it can lead to bashing your head against the wall over why an obvious code mistake might end up working after all - OSIV conveniently updates the entity behind the scenes.
Spring Boot comes with OSIV enabled by default. It can be turned off by simply adding spring.jpa.open-in-view=false to the application properties file. Notably, prior to version 2.0, Spring Boot offered no indications that the pattern was in use by default. But fortunately, from Spring boot 2.0 onwards, a warning message is logged on the application startup signifying its usage to the developers. This encourages looking OSIV up and then deciding on keeping it or not. Prior to that, many applications went to production with OSIV on without the developers ever knowing. And then, as the app got exposed to production data, it could suffer from performance issues in specific flows. In such cases, even if OSIV is correctly identified to be the problem, it could be that removing it is a risky process that might require extensive refactoring, as it's been there since the very first line of code.
To avoid such scenarios, at CIVIC we align with the best practice of turning OSIV off when in the development of a new project. The potential pitfalls it introduces are simply not worth the risk, especially given the fact that the Spring Framework provides many modules that make communication with the database fairly straightforward.
Take a look at our web and design development services to see where we can help.
