Hibernate--cache mechanism + lazy loading

Statement: This post is only for personal study and summary, without any commercial use. If there is any infringement or problem, please contact as soon as possible, and I will delete the post immediately.

 

Hibernate--cache mechanism + lazy loading

 

       As a framework for dealing with database data, Hibernate is naturally designed to operate data efficiently. For some frequently operated data, the caching strategy is an important means to improve its performance, and the hibernate framework supports caching and supports level 1 Reasonable use of cache strategies can greatly improve the efficiency of our operational data, but the inability to use them may cause unnecessary trouble.

 

 

L1 cache

 

      Session cache means placing query results in the temporary storage space of the session (in the first-level cache). The Hibernate framework supports first-level caching by default. The scope of the first-level cache is small. Once the session is closed, the cache is invalid. We use various methods of the framework, such as: get, load, save, update, delete, etc., all support the first level cache.

 

 

 

L2 cache

 

      The second-level cache actually places the queried data in the temporary storage space of the SessionFactory. Because one SessionFactory can create multiple Session objects, the scope is larger than that of the Session cache, and multiple Sessions can share the data in the second-level cache. Of course, the second-level cache cannot store a large amount of data, which needs to be set according to our computer configuration.

 

 

L2 cache configuration steps

 

1. Add a property tag to the hibernate.cfg.xml configuration file to enable the second level cache:

   <!--Enable L2 cache-->

   <propertyname="hibernate.cache.use_second_level_cache">true</property>

 

2. The second-level cache needs to use an additional third-party component: ehcache. We need to copy in the corresponding jar package and store the corresponding ehcache.xml in the src directory. In this configuration file, we can set the size of the second level cache, etc.

 

3. Let the framework recognize the added ehcache cache component and add a property tag to the hibernate.cfg.xml configuration file:

   <!--Let the framework recognize the ehcache cache component-->

   <propertyname="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>

 

4. Set the mapping classes that need to be cached. Here, you only need to specify some classes with frequent query operations. It is not necessary to use the cache for the data that are not frequently operated. Here for example:

   <!-- Store the specified class in the second-level cache, where read-only means that the data in the cache is read-only -->

   <class-cache usage="read-only" class="com.ljh.hibernate.pojo.Student"/>

 

 

The operation data principle of cache

                   

      When querying data, it will first fetch the data from the first-level cache. If it is fetched, it will be used directly. Otherwise, it will be fetched from the second-level cache. If it is fetched, it will be used directly. Otherwise, a statement will be sent to query the database. In this way, the use of first-level and second-level caches will improve access efficiency.

 

 

Attention should be paid to the second level cache

 

      Of course, the use of the second-level cache should be careful, and the frequency of data operations, the hardware configuration of the server, the security of the data, etc. should be considered, so as to make good use of the second-level cache and improve the efficiency of our data operation, otherwise, improper use will cause problems. It will bring unnecessary trouble.

 

 

 

Lazy (lazy loading)

 

Lazy (Hibernate's lazy loading function): Indicates that when querying the current object or related object data, it does not actually access the database. When the non-primary key attribute of the object is used, the query statement is actually sent to access the database. In some cases, the queried data may not be used in the subsequent process, and it will be redundant if query processing is performed. Therefore, the delayed loading function can improve performance and can be used reasonably. Of course, the Hibernate framework extends the delay loading function through Cglib proxy.

 

 

Use lazy places to summarize

 

 

Here is just a brief summary of classes and mappings. In practical application, we have to learn the appropriate choice:



 

 

 

Problems with Lazy

 

      The lazy loading function is the first-level cache used, that is, the memory of the session is used. Under normal circumstances, we will close the session after using up, but after closing, we cannot delay the query data, that is to say, the delay The loading function will fail, and an exception will be thrown: No Session, so this is what we need to solve.

 

 

NoSession exception solution

 

     a, Solution principle: We can not close the session at the dao layer, add a filter through the AOP programming idea learned earlier, and close the session after the data retrieval is completed at the view layer, so that the NoSession exception can be solved. But how to get it? Here I think of the ThreadLocal we learned earlier. We can put the Session object into the Threadlocal object, bind it with the thread, and then get it to the view layer and then close it through ThreadLocal.

 

 

     b. The solution, AOP programming idea, must have thought of the spring framework. Indeed, the Spring framework provides the OpenSessionInViewFilter filter to solve the NoSession exception. Here we only need to configure it. You can configure this filter in web.xml:

<!-- The filter needs to be configured in front of the Struts2 framework filter, otherwise it will not work. -->  
<filter>  
    <filter-name>OpenSessionInViewFilter</filter-name>  
    <filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>  
</filter>  
<filter-mapping>  
    <filter-name>OpenSessionInViewFilter</filter-name>  
    <url-pattern>/*</url-pattern>  
</filter-mapping>   

 

 

 

     c,配置的顺序问题,应该将openSessionInViewFilter配置到Struts2的流程前边,这是因为Filter执行顺序是从上向下的,而且Struts2框架的执行流程基本上包含了整个项目顺序的全部流程,MVC流程框架么,就体现在这里了。配置到Struts2框架的流程后边的过滤器是起不到作用的。



 

      我们可以通过合理使用缓存和lazy机制,使我们的程序变得性能更加强,考虑优化项目时,这两项是必须要考虑的。这些东西看起来是比较虚的内容,还需要我们通过一些小例子和实际应用加深理解。

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326446392&siteId=291194637