Deferred loading and DAO patterns for Hibernate and spring

Hibernate and deferred loading

Hibernate Object-Relational mappings provide two types of object initialization modes: deferred loading and non-deferred loading. Non-deferred loading gets the object itself and all of its associated objects at load time. This may result in the execution of hundreds of SELECT statements when an instance is fetched. When using a two-way association, the problem is magnified, and the entire database is loaded when initialization requests occur. Obviously check each object's relationship and manually delete their dues points, but eventually we may lose the advantage of using ORM tools. A detailed solution is to use the deferred loading mechanism provided by hibernate. This initialization strategy loads a one-to-many and many-to-many relationship of only one of its objects when a class member is accessed. For developers, this approach is transparent, and only a minimum number of requests occur, thus obtaining the best performance. One disadvantage of this technique is that deferred loading requires that the session of the hibernate must remain open when the object is still in use. This can cause an important problem when trying to abstract the persistence layer through the DAO pattern. In order to fully abstract the persistence layer, all database logic, including open, closed sessions, cannot appear at the application level. Most often, the logic is hidden in the DAO's implementation class. A quick and poor solution is to avoid the DAO pattern and include the logic of the data connection in the application layer. This is feasible in small applications, but in large systems this is a design flaw that undermines the extensibility of the application.

Using deferred loading at the Web layer

Fortunately, the spring framework already provides a DAO pattern combined with Hibernate delay-loaded web scenarios. For anyone unfamiliar with the spring framework combination hibernate, I'm not going to go into detail here, but I want you to read the chapter "Hibernate database access with the spring framework." This case is a Web application where spring provides Opensessioninviewerfilter and Opensessioninviewinterceptor. Use either of them to get the same functionality. The only difference is that interceptor runs in the spring container and is configured in the context of the Web application, Fitler runs before spring, and is configured in Web.xml. Regardless of which one is used, they open the hibernate session during a request to the current thread that binds to sessions. Once bound to a thread, an open hibernate session can be used transparently by the DAO's implementation class. The session continues to open to allow deferred loading access to the database. Once the view logic is complete, the hibernate session is closed, either in the filter's Dofilter method or in the Interceptor Posthandle method. The following is a configuration instance:

Interceptor Configuration

<beans>
<bean id="urlMapping"
　　 class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
　　　 <property name="interceptors">
　　　　 <list>
　　　　　　　 <ref bean="openSessionInViewInterceptor"/>
　　　　 </list>
　　　 </property>
　　　 <property name="mappings">
...
</bean>
...
<bean name="openSessionInViewInterceptor"
　　 class="org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor">
　　　 <property name="sessionFactory"><ref bean="sessionFactory"/></property>
</bean>
</beans>

Filter configuration

<web-app>
...　　　
<filter>
　　 <filter-name>hibernateFilter</filter-name>
　　 <filter-class>
　　　 org.springframework.orm.hibernate.support.OpenSessionInViewFilter
　　 </filter-class>
　 </filter>
...　　　
<filter-mapping>
　　 <filter-name>hibernateFilter</filter-name>
　　 <url-pattern>*.spring</url-pattern>
</filter-mapping>
...
</web-app>