Hibernate Level 1 cache and level 2 cache, hibernate Level 1 Cache

Hibernate Level 1 cache and level 2 cache, hibernate Level 1 Cache

The cache is between applications and physical data sources. It is used to reduce the frequency of applications accessing physical data sources and improve the running performance of applications. Data in the cache is the replication of data in the physical data source. during runtime, the application reads and writes data from the cache. Data in the cache and the physical data source will be synchronized at a specific time or event.

The cache medium is generally memory, so the read/write speed is very fast. However, if the volume of data stored in the cache is very large, the hard disk will also be used as the cache medium. The implementation of cache should not only consider the storage media, but also take into account the management of concurrent access to the cache and the lifecycle of the cache data.

Hibernate cache includes Session cache and SessionFactory cache. SessionFactory cache can be divided into two types: Internal cache and external cache. The Session cache is built-in and cannot be detached. It is also called the first-level cache of Hibernate. The built-in cache of SessionFactory is similar to the Session cache implementation method. The former is the data contained in some collection attributes of the SessionFactory object, the latter refers to the data contained in some set attribute packages of the Session. The built-in cache of SessionFactory stores the ing metadata and predefined SQL statements. The ing metadata is a copy of the data in the ing file, the pre-defined SQL statement is derived from the ing metadata in the Hibernate initialization phase. The built-in cache of SessionFactory is read-only, and the application cannot modify the ing metadata in the cache and the pre-defined SQL statement, therefore, SessionFactory does not need to synchronize built-in cache and ing files. The external cache of SessionFactory is a configurable plug-in. By default, SessionFactory does not enable this plug-in. External cache data is a copy of database data, and external cache media can be memory or hard disk. The external cache of SessionFactory is also called the second-level cache of Hibernate.

The two levels of Hibernate cache are located at the persistence layer, which stores copies of database data. What are the differences between them? To understand the differences between the two, we need to have a deep understanding of the two features of the persistence layer cache: the cache scope and the cache's concurrent access policies.

Cache range of The Persistence Layer

The cache scope determines the cache lifecycle and who can access it. The cache scope is divided into three types.

1. Transaction scope: the cache can only be accessed by the current transaction. The cache lifecycle depends on the transaction lifecycle. When the transaction ends, the cache ends the lifecycle. In this range, the cache medium is memory. Transactions can be database transactions or application transactions. Each transaction has its own cache. Data in the cache is usually in the form of correlated objects.

2. Process scope: the cache is shared by all transactions in the process. These transactions may access the cache concurrently, so you must adopt the necessary transaction isolation mechanism for the cache. The cache lifecycle depends on the process lifecycle. When the process ends, the cache ends. The cache within the process scope may store a large amount of data, so the storage media can be memory or hard disk. The data in the cache can be in the form of correlated objects or objects in the form of loose data. The loose object data format is somewhat similar to the object serialization data, but the loose object decomposition algorithm requires faster than the object serialization algorithm.

3. Cluster scope: in a cluster environment, the cache is shared by processes of one or more machines. Data in the cache is replicated to every process node in the cluster environment. Data Consistency in the cache is ensured through remote communication between processes. Data in the cache is usually in the form of loose data of objects.

For most applications, you should carefully consider whether to use the cluster-range cache, because the access speed may not necessarily be much faster than the direct access to database data.

The persistence layer can provide cache in Multiple scopes. If no data is found in the cache of the transaction scope, you can also query it in the cache of the Process scope or cluster scope. If no data is found, you can only query it in the database. The cache of the transaction scope is the first level of the persistence layer, which is usually necessary; the cache of the Process scope or cluster scope is the second level of the persistence layer, which is usually optional.

Cache concurrent access policies at the persistence layer

When multiple concurrent transactions access the same data cached in the persistence layer at the same time, the concurrency problem occurs. Necessary transaction isolation measures must be adopted.

The cache within the process scope or cluster scope, that is, the second-level cache, will cause concurrency problems. Therefore, you can set the following four types of concurrent access policies, each of which corresponds to a transaction isolation level.

Transaction type: Applicable only to managed environments. It provides the Repeatable Read transaction isolation level. This isolation type can be used for data that is frequently read but rarely modified, because it can prevent concurrent problems such as dirty read and non-repeatable read.

Read/write type: Provides Read Committed transaction isolation level. Applicable only in non-cluster environments. This isolation type can be used for data that is frequently read but rarely modified, because it can prevent concurrent problems such as dirty reads.

Non-strict read/write type: Data Consistency between the cache and the database is not guaranteed. If two transactions 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. This concurrent access policy can be used for data that is rarely modified and occasionally dirty read. Read-Only: This concurrent access policy can be used for data that has never been modified, such as reference data.

Transaction-type concurrent access policies have the highest transaction isolation level and the lowest read-only isolation level. The higher the transaction isolation level, the lower the concurrency performance.

What kind of data is suitable for storing in the second-level cache?

1. Rarely modified data

2. Not very important data, allowing occasional Concurrent Data

3. data that will not be accessed concurrently

4. Reference Data

Is it not suitable for storing data in the second-level cache?

1. frequently modified data

2. No concurrency is allowed for financial data

3. data shared with other applications.

Hibernate second-level cache

As mentioned above, Hibernate provides two levels of cache, the first level is the Session cache. Because the lifecycle of a Session Object usually corresponds to a database transaction or an application task, its cache is the cache of the transaction scope. The first-level cache is required and cannot be detached. In the first cache, each instance of the persistence class has a unique OID.

The second-level cache is a pluggable cache plug-in that is managed by SessionFactory. Because the life cycle of the SessionFactory object corresponds to the entire process of the application, the second-level cache is the cache of the Process scope or cluster scope. The loose data of the objects stored in the cache. The second-level object may have concurrency issues, so appropriate concurrent access policies must be adopted. This policy provides transaction isolation level for cached data. The cache adapter is used to integrate the specific cache implementation software with Hibernate. The second-level cache is optional. You can configure the second-level cache on the granularity of each class or set.

The general process of Hibernate's second-level cache policy is as follows:

1) When performing conditional queries, a select * from table_name where… is always issued .... (Select all fields) This SQL statement queries the database and obtains all data objects at a time.

2) put all the data objects obtained into the second-level cache by ID.

3) When Hibernate accesses the Data Object Based on the ID, it first looks up the data object from the Session level cache. If the Session level-2 cache is not found, it will be found from the level-2 cache, query the database and put the result into the cache by ID.

4) when data is deleted, updated, or added, the cache is also updated.

Hibernate's second-level cache policy is a cache policy for ID queries and does not work for conditional queries. Therefore, Hibernate provides a Query cache for conditional queries.

The process of Hibernate's Query cache policy is as follows:

1) Hibernate first sets a Query Key based on the information. The Query Key includes the general information of the request for conditional Query: The parameters required by SQL and the record range (starting position rowStart, maxRows.

2) Hibernate searches for the corresponding result list in the Query cache based on the Query Key. If yes, this result list is returned. If no, Query the database, obtain the result list, and put the entire result list into the Query cache based on the Query Key.

3) the SQL statement in the Query Key involves some table names. If any data of these tables is modified, deleted, or added, these related Query keys must be cleared from the cache.