Explain the cache and secondary cache in the Hibernate framework of Java in detail

cache

Today, let's talk about the entity state and Hibernate cache in hibernate. 1) First, let's take a look at entity states: entity states are mainly divided into three types: transient, persistent and detached. I should understand it by reading English. Transient: it means that the data does not correspond to the data in the database. Persistent: it means that the data corresponds to the data in the database, and any changes will be reflected in the database. Detached: refers to the data corresponding to the data in the database, but since the session is closed, its modifications will not affect the database records. Let's use the following code directly:

We see the code. First, we define an object user. Before saving, it is a transient state, and there is no corresponding record in the database. After we save and submit the changes, the user becomes persistent and has a corresponding record in the database. When we close the session, the user becomes detached, and its changes will not be reflected in the database unless we manually call the corresponding update and addition methods such as saveOrUpdate. And when we directly want it to go from persistent to transient state, what should we do? You can delete it directly. After deletion, the object has no corresponding record in the database, which becomes a transient state. Hibernate's state transition is relatively simple. When it is in transient state, the database does not have corresponding records, while both persistent and detached have corresponding records, but the only difference is that detached is in the state after the session is closed. What is the difference between transient and detached? The problem is whether there are corresponding database table records. 2) After reading the status, let's take a look at the cache of hibernate. There are two kinds of Hibernate cache, level 1 cache and level 2 cache. L1 cache: the so-called L1 cache is also called internal cache. Level 2 Cache: it includes application level cache. In Hibernate, it is called sessionfactory cache. The other is distributed cache, which is the safest cache method. Look directly at the procedure:

Look at the results:

In the example, we use load twice, but there is only one SQL statement in the result, which indicates that it has been queried only once. Why? This is why hibernate's cache works. After the first query, hibernate will put the found entities in the cache. The next query will first check the cache to see if there are entities with corresponding IDs. If there are, they will be taken out directly. Otherwise, the database will be queried. Let's modify the code to:

See the results:

After we delete the user from the cache, the second query is also taken directly from the database.

Let's look at the entity class first

The mapping file is omitted. Everyone should be able to write it. Let's look at the hibernate configuration file:

We see the provider_ Class, we specify the ehcache provider class, so we also need ehcache XML in classpath:

Next, let's take a direct look at the test method:

After running, you can see:

We can see that it only performs one sentence search, but does not take out the ID for search in the second query, which is mainly due to the L2 cache. Let's first analyze the code in the test method. In the test method, we open two sessions and create two queries for the same query. However, two sessions can share the cache, which is the L2 cache and the sessionfactory cache. As long as our session is created by the same sessionfactory, we can share the L2 cache and reduce the interaction with the database. Let's take another look at the meaning in the configuration file:

If we need to use L2 cache, we first need to configure:

Perform L2 cache for account opening, and then through:

Specify the class to provide L2 cache. Generally, we use ehcache. I don't use other ones for the time being, so I won't talk about them for the time being. As in our example just now, we only need to configure the above two, which can run normally and use the L2 cache. So what's the third sentence for?

This configuration indicates that we need to use the cache when querying. If we need this, we need to call query in advance Setcacheable (true) this method to enable. Let's look at the code together (let's not enable caching first):

The output here is:

We can see that it does not use the cache, because we use the list here, and the list only writes to the cache and does not read. So there will be two queries here. Let's revise it:

See the two red sentences of code, which are the two codes we added to enable query caching. Now we see the results:

There's only one query left. Why? Just at those two red lines of code, we turned on the cache. Remember, we need to use it twice. Query caching can only be used when both queries are set to be cacheable. Criteria is similar. In order to prevent some children's shoes from forgetting how criteria is written, I'd better put the code:

Let's look at the results: