Solution and profound analysis of Hibernate lazy loading exceptions

Solution and profound analysis of Hibernate lazy loading exceptions

Cause:

Hibernate allows delayed loading of associated objects and attributes, provided that this operation is performed within the same Hibernate session range. if this happens, when the service layer returns a domain object that enables the delayed loading function to the web layer, and the web layer accesses these objects or attributes that require delayed loading, an access exception occurs because the session for loading the domain object is closed and thus cannot be accessed.

 

Solution:

 

We can use a filter to bind a Hibernatesession to a web request. This ensures that the session is enabled during the entire request process and supports delayed loading.

Spring provides this filter ---- OpenSessionInViewFilter, which binds the Hibernate session to the request thread, and the session is automatically managed by the Spring Transaction Manager. even if transactions at the Service layer are completed, the session is enabled to support delayed loading.

The specific method is to configure this filter in web. xml:

 

       
  
   OpenSessionInViewFilter
                                            
  
   org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
   
 
     
  
   OpenSessionInViewFilter
       
  
   *.action
  
 

 

 

Advantages and disadvantages of this solution:

 

For example, in a real project:

If the User and Department are multi-to-one object associations, we need to display the user information on the page. The Department in the user uses lazy loading.

 

With OpenSessionInViewFilter, the service layer provides a queryUser () method to handle this problem. Lazy loading is automatically triggered when the web layer initiates a call. it's amazing to use filters. It's easy to find out what you want to use. If the project is not large, the service-Layer Code is well developed and maintained.

 

Let's think about whether there will be performance problems. If the project is too large and has a high concurrency, it will not be so nice to do so. Why? Every web request is bound to a Hibernate session. After all requests are bound to a session, it means that all requests will occupy a data connection until the request is processed! That is to say, web requests occupy much longer data connections than they used to, and even some web requests do not need to use data connections at all. This concurrency of data connection resource access will lead to performance bottlenecks. most of our bottlenecks come from databases ~

 

Is there any good solution?

Yes, let the requests that need to connect to the database bind the session. You don't need to bind the session. Yes, but I still don't know how to add a filter before the filter.

It can be implemented, that is, OpenSessionInViewFilter is not used. How can I solve the lazy loading exception? Let's change our mindset to implement lazy loading in the service, so that it will not cross the service to the web layer. this requires the design of a Multi-Element interface at the service layer. In the preceding example, I wrote two interfaces at the service layer: getUserWithDepartment () and getUserWithoutDepartment ().

 

ITOOProject Experience Summary:

 

In ITOO, Hibernate is not used for lazy loading. At that time, the system was slow due to unnecessary Association queries, which was solved by optimizing SQL statements. Why didn't we use lazy loading? Because our delayed loading operations completely exceed the Hibernate session range, one is the session in the EJB container, and the other is the Hibernate session in Spring, which is out of range and cannot be used.