We saw in the preceding section that in order to defer fetching until the associated entity is needed, we set the fetch type of the associated entities as LAZY. When we try to access these associated entities in our presentation layer (if they are not initialized in our business (service) layer), an exception is thrown by Hibernate, called LazyInitializationException. When the service layer method completes its execution, Hibernate commits the transaction and closes the session. So, by the time the view is rendered, the active session is not available to fetch the associated entities.

To avoid LazyInitializationException, one of the solutions is an open session in view. This means that we keep the Hibernate session open in view so that the presentation layer can fetch the required associated entities, and then close the session.

In order to enable this solution, we need to add a web filter to our application. If we are using Hibernate on its own, we need to add filter, OpenSessionInViewFilter; if we are using JPA, then we need to add filter OpenEntityManagerInViewFilter. As we are using JPA with Hibernate in this chapter, the following is the snippet to add filter:

<filter>
    <filter-name>OpenEntityManagerInViewFilter</filter-name>
    <filter-class>org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter</filter-class>
   ....
</filter>
...
<filter-mapping>
    <filter-name>OpenEntityManagerInViewFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

The solution provided by the Open Session in View (OSIV) pattern to avoid the exception might not look terrible at first glance; however, there are problems with using the OSIV solution. Let's go over some issues with the OSIV solution:

1. The service layer opens the transaction when its method is invoked and closes it when the method execution completes. Afterward, there is no explicit open transaction. Every additional query executed from the view layer will be executed in auto-commit mode. Auto-commit mode could be dangerous from a security and database point of view. Due to the auto-commit mode, the database needs to flush all of the transaction logs to disk immediately, causing high I/O operations.
2. It will violate the single responsibility of SOLID principles, or separation of concern because database statements are executed by both the service layer and the presentation layer. 
3. It will lead to the n + 1 problem that we saw in the preceding Hibernate n + 1 problem section, though Hibernate offers some solutions that can cope with this scenario: @BatchSize and FetchMode.SUBSELECT, however, would apply to all of the business requirements, whether we want to or not.
4. The database connection is held until the presentation layer completes rendering. This increases the overall database connection time and impacts transaction throughput.
5. If an exception occurs in the fetching session or executing queries in the database, it will occur while rendering the view, so it will not be feasible to render a clean error page to the user.