Cache Mechanism of hibernate review-level cache, level-2 cache, and query Cache

Before introducing the cache mechanism of hibernate, let's take a look at what cache is:
Cache: a very common concept in the computer field. The cache is a collection. It is between an application and a permanent data storage source (such as a file or database on a hard disk). Its function is to reduce the frequency of applications directly reading and writing permanent data storage sources, this improves the Running Performance of applications. The cached data is the copy of the data in the data storage source and the cached physical medium is usually the memory.
Anyone familiar with jdbc knows that a connection pool is usually used when a database needs to be connected. What is the difference between a connection pool and a slow connection pool?
Similarities: both of them can be in the memory, and are implemented in the same way to improve performance.
Difference: the connection pool is a heavyweight pool, that is, the resources in the pool are very valuable.

Next, let's take a look at the cache mechanism in hibernate: Level 1 cache, level 2 cache, and query cache.

Level 1 cache:
1. In hibernate, a thread corresponds to a session, and a thread can be considered as a session, that is, the session is bound with the thread.
2. Understanding Level 1 cache:
The session Interface contains a series of java interfaces, which constitute a session-level cache, as long as the session instance's life cycle is not over, the cached objects in the cache will not die. Iterate, load, get, save, and so on all use a level-1 cache.
3. First-level cache cleanup
The session has a cache. The objects in the cache are called persistent objects, which correspond to relevant records in the database. Sessions execute related SQL statements according to the changes of objects in the cache at certain time points, to synchronously update the database. This process is called clearing the cache. By default, the session clears the cache at the following time points:
(1) When a transaction is committed, the cache session. flush () will be cleared first ();
(2) When the persistence object in the cache changes, the cache is cleared first to ensure the latest state of the persistence object.
(3) display the call session. flush ();
Clear related knowledge points:
Session. flush (); clears the cache. The cached Sino-German persistence object will not be lost and an insert statement will be generated.
Session. clear () clears the cache, and persistent objects in the cache are lost.
Session. reflush () allows the session to synchronize with the database, execute a query, display the latest information of the database, and update the state of the locally cached object ..
After a session loads an object, the session copies a snapshot of its value type attribute. When the cache is cleared, the current attributes and snapshots of the object are compared, to determine which attributes of an object have changed,
If the SQL statement is changed, the SQL statement is not executed ..
When you clean up the cache without using refresh, You need to compare the objects in the first-level cache with those in the snapshot. Otherwise, an updata statement will be generated during submission.
4. Other knowledge points
Iter = session. createQuery ("from Student s where s. id <5"). iterate ();
While (iter. hasNext ()){
Student student = (Student) iter. next ();
System. out. println (student. getName ());
Iterate has n + 1 problems when no cache is used.
The first iterate query will issue N + 1 SQL statement. The first SQL statement queries all IDs, and then queries the object based on the id. If there are N IDs, it will issue N statements to query objects.
Iterate queries different attributes. The first-level cache does not cache, because the first-level cache is used to cache object objects.

There cannot be a total of first-level caches between sessions, and the first-level cache will expire with the disappearance of sessions.

Secondary cache:

1. The second-level cache needs to be managed by sessionFactory. It is a process-level cache that can be used by all users and is shared.
2. The second-level cache is complicated. It is generally implemented by a third-party product. hibernate only provides a simple implementation, which is implemented by hashtable.
3. Application scenarios: data that remains unchanged for a long time.
4. configuration steps:
(1) You can set the default value for ehcache. xml. All classes follow this configuration, or you can configure an object separately.
(2) configure the cache in the hibernate. cfg. xml configuration file to let hibernate know which level 2 cache we are using. Including configuration attributes: whether to enable the second-level cache and second-level cache provider.
(3) manually specify the object classes to be cached, and configure them in hibernate. cfg. xml.

Or
Before the id tag in the ing File
The usage attribute indicates that the cache policy is used. Generally, read-only is used first, indicating that if the data is stored in the cache, it cannot be modified because the frequently modified data does not need to be stored in the cache.
The read-only policy is highly efficient because the cache cannot be changed, but dirty data may occur. The solution to this problem can only rely on Cache timeout because the object data may have been modified, however
The cache is not changed, which causes data not to be synchronized, that is, dirty data.
Read-write when the persistence object changes, the cache will change and the database will also change. In this way, the lock must be added, which is slower than read-only.
5. knowledge points:
The level-2 Cache must be managed by sessionfactory and cleared by sessionfactory. You can call the evict method.
After data is queried, the data is stored in the second-level and first-level caches by default. We can also control whether the queried data is stored in the cache. That is to say, we can control the exchange between the first-level cache and second-level cache.
Session. setCacheMode (CacheMode. IGNORE); do not place data in the first-level cache in the second-level cache.
Like a level-1 cache, level-2 Cache does not store query data for common attributes. This is the same as level-1 cache and only stores object objects.
Session-level caching does not significantly improve performance because the lifecycle is too short.

Query cache:
1. Both the level-1 cache and level-2 Cache store the object. If you query the data of common attributes of an object, you can only store the data in the query cache. The query cache also stores the id of the object to be queried.
2. the lifecycle of the query cache is uncertain. When the associated table is modified (via hibernate), the query cache lifecycle ends.
3. the query cache is disabled by default and can be configured in hibernate. cfg. xml. True . You must manually start the query cache in the program and enable the setCacheable (true) method in the query interface.
4. the query cache is not very meaningful. The query cache indicates that the data queried by the list method or the iterate method is stored in the white space. We rarely see identical condition queries during the query, this means that the hit rate is low,
The data in the cache is always changing. Unless data with the same conditions is queried for multiple queries, that is, the returned results are always the same, so that the cache configuration makes sense.