SSH Framework Online Mall project 16th war Hibernate two cache processing home hot display _java

Online mall home are hot goods, then the click rate of these products is very high, when users click on a hot item after the need to enter the details of the product page, like Taobao inside that. Then each click to the background to query the details of the product, it will send the corresponding SQL statements, each refresh the detailed page will also send SQL statements, so, the performance will certainly be greatly affected. Then use the hibernate level two cache to solve this problem.

Some people might think, we can use redirects, so that when the user first visit the information found to put in the session, after each user refresh can go to the session to take, so you do not have to go to the database query, which is reasonable, but can not solve the above problems, Because we want to solve is multi-user to access the same product, to click on the same product, redirect can only ensure that the same user to click or refresh. But the level two cache solves these problems.
Let's start with a detailed explanation of the level two caching technology based on Hibernate4.3, and then make a specific configuration for this project.

1. Hibernate4.3 level two cache basic configuration
Unlike Hibernate3, Hibernate4.3 's core package does not have a cache-related class, and we need a cache jar package to use level two caching, from the officially downloaded hibernate-release-4.3.11.final lib The jar package required for the level two cache in the/optional/ehcache is added to the project first. As follows:

We then configure the level two cache-related configuration in Hibernate.cfg.xml:

Then we open the Tomcat server, and then visit the home page, click on the hot items, the background is no longer send SQL statements, we may wonder, is the level two cache is so simple? Configure the above two items to be done? In fact, up to now, the level two cache has been in effect because it has a default configuration, in the above that Ehcache-core-2.4.3.jar has a ehcache-failsafe.xml file, which has a default configuration, we will be more specific analysis. Let's first analyze the Hibernate query strategy:

2. Hibernate4.3 's query strategy
Hibernate supports two ways of querying: Session Query and HQL query.
There are methods such as Session.save () update () () () load () in session, which simply manipulate one record and support level two caching by default without any configuration. Therefore: The read-only configuration is in effect for the session. If READ-ONLY is configured in the two level cache in the session, the Session.update () and delete () operations fail, and if they want to succeed, they need to be configured as Read-write. However, save () and get () load () are successful.
HQL: This method is used by default to manipulate multiple records, such as the list () and the Executeupdate () method. In this way the configuration of the default level two cache including Read-only is invalid. The HQL list () queries multiple records, queries the database directly, and gives the results of the query to level two caching, making it easier to call the get () and load (). Executeupdate is also not support level two cache, but also directly to the database update, Hibernate will ensure that the database and cache synchronization. Note: HQL is not a Save () method, and you can only call the Session.save () method if you need to insert data.
"Note": The first-level cache (default presence) in Hibernate is also known as the session-level cache and is not used to promote performance, but to handle transactions; The secondary cache is the Sessionfactory cache, which is valid for all sessions. The lifecycle is the same as Sessionfactory (Sessionfactory is a single case and is created when the project is started).
For the specific query strategy, let's look at this picture below:

"Note": picture text If too small, you can drag the picture to the new window to see ~
The above is the Hibernate query strategy, let's continue to look at the level two cache configuration.

3. Hibernate4.3 level Two cache Advanced Configuration
As mentioned above, we can use level two caching because we have two items configured in Hibernate.cfg.xml, because there is a default configuration, let's take a look at this default configuration first:

<ehcache xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance" xsi:nonamespaceschemalocation= ". /config/ehcache.xsd > 
 
 <!--if the cache memory overflows, it is stored to the hard disk space--> 
 <diskstore path= "Java.io.tmpdir"/> 
 
 <defaultcache 
 maxelementsinmemory= "10000": <!--the number of maximum objects supported by memory--> 
 eternal= "false":<!--object is permanently active , it is recommended to be false so that the following two parameters are valid--> 
 timetoidleseconds=:<!--object's interval, default unit is seconds. That is, 60 seconds later, if no one has used this object, the--> timetoliveseconds= ":<" is destroyed in advance the lifecycle of the object, the 
 default unit is seconds--> 
 overflowtodisk= "true": <!--whether to support overflow to the hard disk, it is recommended to true--> 
 maxelementsondisk= "10000000":<!--the number of maximum objects supported on the hard disk--> 
 Memorystoreevictionpolicy= "LRU":<!--object replacement policy--> 
 /> 
</ehcache> 

The explanation for the default configuration is already in the comments above, and we now know that because of this default configuration, the Hibernate4.3 level two cache is properly executed. Now if we want to cache our own configuration, we need to create a new Ehcache.xml file in the SRC directory, and then reconfigure the above configuration items. We have to test each configuration, before the test, I first show the first page of the situation posted out, and a number, and so will test when the good description:

Above is the content that the homepage displays, Hibernate has helped us to find out the display information from the database, and has already shown good. We'll make them a number, and we'll be able to analyze them when we test the cache. Now let's start by testing the cache configuration entry above:
Test One: test the number of objects in memory. Change the configuration to the following:

<defaultcache 
  maxelementsinmemory= "6" <!--setting only supports caching of 6--> 
  eternal= "true" 
  overflowtodisk= " False " 
  memorystoreevictionpolicy=" FIFO:<!--Advanced First out--> 
  /> 

After the configuration is good, we restart the server, open the first page, because the configuration is 6, so only the last found in the cache of 6 records, that is, number 3-8, we click on any one of the goods in 3-8 to enter the product detail page, pay attention to see the background of the console does not output any query information, The description does not send an SQL statement, but when we click on the item numbered 2, the background sent a SQL statement, that is, query the database, we back click 2 Merchandise, there is no more SQL statements, the description has been put into the cache, but the cache only supports 6 data, because the configured object substitution strategy is advanced first out , so just the number 3 in the cache has been removed, we clicked on 3 to try, sent a SQL statement, so the test finished, the level two cache performs normally.
Test Two: the life cycle of the test object. Change the configuration to the following:

<defaultcache 
 maxelementsinmemory= 
 eternal= false <!--to set the following life cycle--> 
 timetoidleseconds= "timetoliveseconds=" " 
 overflowtodisk=" false " 
 memorystoreevictionpolicy=" FIFO " 
 /> 

The cache is configured with a time of 40 seconds and is removed if 20 seconds are not operational. Since we have 100 records, so the above number 1-8 is in the cache, we open the server, click on a random, such as click Number 8, did not emit SQL statements, normal, 20 seconds later, then click Number 8, sent a SQL statement, indicating that our configuration of the life cycle into effect. Note Here, you cannot configure too short, such as configuration 10 seconds, because Tomcat boot also takes several seconds, if the configuration is less, not testing may have time to ... That's not going to do.
Test Three: test whether the level two cache supports hard disk storage.

<defaultcache 
 maxelementsinmemory= "4" 
 eternal= "false" <!--false to set the following life cycle--> 
 timetoidleseconds= "timetoliveseconds=" 
 overflowtodisk= "true" <!--configured to TRUE to support hard disk storage--> 
 memorystoreevictionpolicy= "FIFO" 
 /> 

We set the support for hard disk storage to TRUE and configured the maximum two cache memory to 4. Reboot the server because the level two cache has up to 4 records, so it must be number 5-8, click 5-8 definitely does not send SQL statements, but when we click 1-4, also does not send SQL statements, because we set up to support hard disk storage, Hibernate will query results exist on the hard drive, So we can also get the data directly, do not need to send SQL statements.
Test Four: test the replacement policy for level two cache

<defaultcache 
 <!-- 
 FIFO has been eliminated, no longer used 
 ... LRU: Least recently accessed algorithm (Time policy), will ignore the frequency of access, from now the most remote access will be replaced 
 LFU: Most recently the most unused algorithm (frequency measurement), will ignore the access time, the least frequency of access will be replaced 
 --> 
 maxelementsinmemory= "3" 
 eternal= "false" <!--to set the following life cycle--> 
 timetoidleseconds= 
 timetoliveseconds= 
 overflowtodisk= "false" <!--configured true to support hard disk storage--> 
 memorystoreevictionpolicy= "LFU" 
 /> 

As the name suggests, LRU and LFU are concerned about the last access time and frequency of visits, we take LFU to give examples, now we set the maximum storage for 3 records, that is, number 6-8, now we access the number 63 times, number 72 times, number 81 times, will not send SQL statements, We visit number 7 again, sent the SQL statement, now number 7 exists in the cache, number 8 has been removed, because it has the fewest visits, we can click the number 8 again to test, issued a SQL statement, test success. If it is LRU, then the number 6 has just been removed because the number 6 was first accessed.
Here, I believe that you have mastered the use of level two cache, the test of level two cache here. The following for our online mall project to do the configuration.

4. The actual configuration of the online shopping mall project
We configure the two cache maximum record number of 1000, set a lifecycle of 120 seconds, interval of 60 seconds, support hard disk storage, and the use of frequency first (LFU) replacement strategy, because the user clicks High, must be placed in the two level cache.

<ehcache xmlns:xsi= "Http://www.w3.org/2001/XMLSchema-instance" xsi:nonamespaceschemalocation= ". /config/ehcache.xsd > 
 
 <!--if the cache memory overflows, it is stored to the hard disk space--> 
 <diskstore path= "Java.io.tmpdir"/> 
 
 <defaultcache 
  maxelementsinmemory= "1000" 
  eternal= "false" 
  timetoidleseconds= " 
  timetoliveseconds= "overflowtodisk=" " 
  true" 
  memorystoreevictionpolicy= "LFU" 
  /> 
</ Ehcache> 

Well, combined with the online mall this project, the Hibernate4.3 two cache configuration and use of the introduction is over.

Original address: http://blog.csdn.net/eson_15/article/details/51405911

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.