The difference between Hibernate cache level and level two cache

First-level caching:
is the session-level cache. A session does a query operation that puts the results of this operation in a first-level cache.
If in a short time this session (must be the same session) and do the same operation, then hibernate directly from the first cache, and will not be connected to the database, fetch data.
It is a built-in transaction-scoped cache and cannot be uninstalled.
Second-level cache:
is the sessionfactory level cache. As the name implies, query results are cached to the level two cache when queried.
If a session created by the same sessionfactory performs the same action, Hibernate takes the result from the level two cache and no longer connects to the database.
This is an optional plug-in cache, which, by default, does not enable this plugin for sessionfactory.
　　Can be configured at the granularity of each class or collection. the cache adapter is used to integrate the specific cache implementation software with Hibernate.

Strictly speaking, the sessionfactory cache is divided into two categories: built-in caches and external caches. In our usual sense, level two caches refer to external caches.

The built-in cache is similar to the session level cache implementation. The former is the data contained in some collection properties of the Sessionfactory object, which refers to the data contained in some of the collection properties of the session

Mapping metadata and predefined SQL statements are stored in Sessionfactory's built-in cache.
The mapping metadata is a copy of the data in the mapping file;
The predefined SQL statements are deduced from the mapping metadata during the hibernate initialization phase.
Sessionfactory's built-in cache is read-only, and the application cannot modify the mapping metadata and predefined SQL statements in the cache, so sessionfactory does not need to synchronize the built-in cache with the mapped file.

Hibernate's Level Two cache is located in the persistence layer, which is a copy of the database data.

Two features of the cache:
Scope of the cache
Concurrent access Policy for caching

1. Scope of the cache
Determines the life cycle of the cache and who can access it. The scope of the cache falls into three categories.
Transaction scope
Process scope
Cluster range
Note:
For most applications, it should be prudent to consider whether a cluster-wide cache is required, because the speed of access is not necessarily faster than accessing database data directly.
　　　　The transaction-scoped cache is the first-level cache of the persistence layer, which is usually required, and the process-wide or cluster-wide cache is the second-level cache of the persistence layer, which is usually optional.

2. Cached Concurrency Access Policy
Concurrency issues occur when multiple concurrent transactions access the same data in the persisted layer's cache, and must take the necessary transaction isolation measures.

Concurrency issues occur in a process-wide or cluster-wide cache, which is a second-level cache.
You can therefore set the following four types of concurrent access policies, each of which corresponds to a transaction isolation level.
Transactional concurrency access policy is the highest transaction isolation level, with the lowest read-only isolation level. The higher the transaction isolation level, the lower the concurrency performance.

A transaction type: Applies only in managed environments. It provides the REPEATABLE read transaction isolation level.
For data that is often read but rarely modified, this type of isolation can be used because it prevents concurrency problems such as dirty reads and non-repeatable reads.
B Read-write: Provides the Read committed transaction isolation level. Applicable only in non-clustered environments.
For data that is often read but rarely modified, this type of isolation can be used because it prevents concurrency problems such as dirty reads.
C non-Strict read-write: does not guarantee the consistency of the cache and the data 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 that data to avoid dirty reads as much as possible.
This concurrent access policy can be used for data that is rarely modified and allows for occasional dirty reads.
D Read-only: This concurrency access policy can be used for data that is never modified, such as reference data.

What data is suitable for storage in the second level cache?
1. Data that is rarely modified
2. Data that is not very important, allowing occasional concurrent data to occur
3. Data that will not be accessed concurrently
4. Reference data

Not suitable for storing data in a second level cache?
1. Frequently modified data
2, financial data, not allowed to appear concurrency
3. Data that is shared with other applications.

The general process for Hibernate's level two cache 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) Put all the obtained data objects into the second level cache based on the ID.
3) When hibernate accesses the data object according to the ID, it is first checked from the session cache, and if the level two cache is configured, it is checked from the level two cache, and the database is not found, and the result is placed in the cache by ID.
4) Update the cache while deleting, updating, and adding data.

Note:
　　Hibernate's level two cache policy, which is a cache policy for ID queries, has no effect on conditional queries. To do this, hibernate provides a query cache for conditional queries.

The process for the query cache policy is as follows:
1) Hibernate first consists of this information to form a query Key,query Key including the request general information of the conditional query: Sql,sql required parameters, record range (starting position rowstart, maximum number of records maxrows), and so on.
2) Hibernate finds the corresponding result list based on this querykey to the query cache. If present, then return the list of results, and if not, query the database, get a list of results, and put the entire result list into the query cache based on Querykey.
3) SQL in Query key involves some table names, and if any of these tables are modified, deleted, incremented, and so on, the related querykey are emptied from the cache.

Reprint to: http://blog.sina.com.cn/s/blog_6a7f00ed0101nau9.html

The difference between Hibernate cache level and level two cache