Introduction to caching mechanism of hibernate

Cache caching, which is between an application and a physical data source, is designed to reduce the frequency of application access to physical data sources, thereby improving the operational performance of the application. The data in the cache is a copy of the data in the physical data source, the application reads and writes data from the cache at run time, and the data for the cache and the physical data source is synchronized at a particular time or event.

Cached media is generally memory, so read-write speed is very fast. However, if the amount of data stored in the cache is very large, the hard disk is also used as the caching medium. The implementation of caching takes into account not only the stored media, but also the lifecycle of concurrent access and cached data that manages the cache.

The Hibernate cache includes session caching and Sessionfactory caching, where the sessionfactory cache can be divided into two categories: built-in caching and external caching. The session's cache is built-in, cannot be unloaded, and is also called the Hibernate first-level cache. The Sessionfactory built-in cache and session cache are similar in implementation, which is the data contained in some collection properties of the Sessionfactory object, which refers to the data contained in some collection properties of the session. Sessionfactory's built-in cache includes mapping metadata and predefined SQL statements, mapping metadata is a copy of the data in the mapping file, and predefined SQL statements are deduced from the mapping metadata at the hibernate initialization stage, The Sessionfactory built-in cache is read-only, and the application cannot modify the mapped metadata and predefined SQL statements in the cache, so sessionfactory does not need to synchronize the built-in cache with the mapping file. The Sessionfactory external cache is a configurable plug-in. By default, Sessionfactory does not enable this plug-in. The external cached data is a copy of the database data, and the external cached media can be either memory or a hard disk. Sessionfactory's external cache is also referred to as the second-level cache of Hibernate.

The hibernate two-level cache is located in the persistence layer, storing all copies of the database data, so what is the difference between them? To understand the difference, there is a need to understand the two characteristics of the cache of the persistence layer: the scope of the cache and the concurrent access policy for the cache.

The scope of the cache for the persistence layer

The scope of the cache determines the life cycle of the cache and who can access it. The scope of the cache is divided into three categories.

1 Transaction scope: Cache can only be accessed by current transaction. The life cycle of the cache depends on the lifecycle of the transaction, and when the transaction ends, the cache ends the lifecycle. In this range, the cached media is memory. A transaction can be a database transaction or an application transaction, and each transaction has its own cache, and the data in the cache usually takes the form of an interrelated object.

2 Process scope: Caching is shared by all transactions within the process. These transactions may be concurrent access caching, so the necessary transaction isolation mechanism must be taken on the cache. The lifecycle of the cache depends on the lifecycle of the process, and the cache ends the lifecycle at the end of the process. Process-scoped caching may hold a large amount of data, so the stored media can be memory or a hard disk. The data in the cache can be either an interrelated object form or an object's loose data form. The Loose object data form is somewhat similar to the serialized data of the object, but the object is decomposed into loose algorithms that require faster than the object serialization algorithm.

3 Cluster scope: In a clustered environment, caching is shared by a machine or by a process of multiple machines. The data in the cache is replicated to each process node in the cluster environment, where the data in the cache is guaranteed to be consistent between processes, and the data in the cache usually takes the form of loose data for the object.

For most applications, it is prudent to consider the need to use cluster-wide caching because the speed of access is not necessarily faster than accessing database data directly.

The persistence layer can provide a wide range of caches. If the corresponding data is not found in the transaction-scoped cache, it can be queried within the process scope or cluster-wide cache, if it is not found, then only to the database. The transaction-scoped cache is the first-level cache of the persistence layer, which is usually required; the process-scoped or cluster-scoped cache is the second-level cache of the persistence layer and is usually optional.

Concurrent access policies for the cache of persistent layers

When multiple concurrent transactions simultaneously access the same data for the cache of the persisted layer, the concurrency problem is caused and the necessary transaction isolation measures must be used.

Concurrency issues occur in a process-wide or cluster-wide cache, which is a secondary cache. Therefore, you can set the following four types of concurrent access policies, each of which corresponds to a transaction isolation level.

Transaction type: Only applicable in a managed environment. It provides the REPEATABLE read transaction isolation level. This type of isolation can be used for data that is often read but rarely modified, because it prevents dirty reads and non-duplication of concurrency problems.

Read-write: The Read Committed transaction isolation level is provided. Apply only in a non-clustered environment. For data that is often read but rarely modified, this isolation type can be used because it prevents dirty reading of such concurrency problems.

Non-rigorous read-write type: does not guarantee the cache and data consistency in the database. If there are two transactions that can access the same data in the cache at the same time, you must configure a very short data expiration time for the data to avoid dirty reads as much as possible. 　　This concurrent access policy can be used for data that is rarely modified and allows occasional dirty reads. Read-only: This concurrent access policy can be used for data that is never modified, such as reference data.

Transactional concurrency access policy is the highest level of transaction isolation, with the lowest isolation level for read-only types. The higher the transaction isolation level, the lower the concurrency performance.

What data is suitable for storage in the secondary cache?

1. Data that is rarely modified

2, not very important data, allow occasional concurrent data

3, data that will not be accessed concurrently

4. Reference data

Not suitable for data stored in a second level cache?

1. Data that is often modified

2, financial data, absolutely not allowed to appear concurrent

3. Data shared with other applications.

Hibernate's Level two cache

As mentioned earlier, Hibernate provides a level two cache, with the first level being the session cache. Because the lifecycle of a session object typically corresponds to a database transaction or an application transaction, its cache is a transaction-scoped cache. The first level cache is required and is not allowed and in fact cannot be compared to dismount. In the first level cache, each instance of the persisted class has a unique OID.

The second level cache is a pluggable cache plug-in that is managed by sessionfactory. Because the lifecycle of the Sessionfactory object corresponds to the entire process of the application, the secondary cache is a process-wide or cluster-wide cache. Loose data for objects stored in this cache. Second-level objects may have concurrency problems, so an appropriate concurrency access policy is required, which provides a transaction isolation level for the cached data. The caching adapter is used to integrate the specific cache implementation software with the hibernate. The secondary cache is optional and can be configured with a second level cache on the granularity of each class or collection.

The general process of Hibernate's level two caching strategy is as follows:

1 when the condition is queried, always issue a SELECT * FROM table_name where .... (select all fields) such SQL statements query the database and get all the data objects at once.

2 All the data objects obtained are put into the second level cache according to the ID.

3 when hibernate according to ID access to data objects, first from the session-level cache, check, if configured with a level two cache, then from the level two cache, check, and then query the database, the results in accordance with the ID into the cache.

4 when deleting, updating, and adding data, update the cache at the same time.

Hibernate's level Two caching strategy is for the cache policy for the ID query, and it has no effect on the conditional query. To do this, hibernate provides the query cache for conditional queries.

The procedure for Hibernate's query caching policy is as follows:

1) Hibernate first based on this information to form a query Key,query Key includes the request general information of the conditional query: SQL, SQL required parameters, record range (starting position rowstart, maximum number of records maxrows), etc.

2 Hibernate according to this query key to the query cache to find the corresponding results list. If so, return the list of results, if not, query the database, get a list of results, and put the entire result list into the query cache according to the query key.

3 The SQL in Query key involves some table names, and if any of these tables are modified, deleted, incremented, and so on, the associated query key is emptied from the cache.