Detailed configuration of the hibernate cache

Hibernate application caching: Because the application accesses the database, the cost of reading and writing data is very high, and the use of persistence layer caching can reduce the interaction between the application and the database, that is, the accessed data is saved in the cache, and the application accesses the accessed data again, and the data can be obtained from the cache instead of the database.

At the same time, if the data in the database is modified or deleted, the cached data corresponding to the data will also be modified or deleted synchronously, so as to maintain the consistency of the cached data. Hibernate's second-level cache is managed by the SessionFactory object and is an application-level cache. It caches persistent objects for the entire application, so it is also called "sessionfactory cache".

Hibernate provides two levels of cache, the first level of cache is the session level cache, which is the transaction-wide cache. This level of caching is managed by Hibernate and generally does not require intervention; The second level of caching is the sessionfactory-level cache, which is a process-wide or cluster-wide cache. This level of caching can be configured and changed, and can be dynamically loaded and unloaded.

Hibernate also provides a query cache for query results, which relies on a second-level cache.

The use of caching is an important means to optimize the performance of application systems. Proper use of caching can greatly improve the operational efficiency of the application system.

The cached objects in the Hibernate L2 cache can be shared by the session object of the entire application, and the newly created session object can still be used even if the current session object is closed. After querying data using Hibernate's L2 cache, the session object will first look in the cache for cached data hits. If not, look for a second-level cache.

If there is, the hit data will be returned directly; Otherwise, query the database.

When you use Hibernate's built-in method to query data, it will automatically be stored in the first-level cache, and if the next SQL statement is the same as the last time, the data will be directly taken out of the cache and the database will not be queried.

The first level of caching is the session-level cache, which is a transaction-scoped cache that is managed by Hibernate and generally requires no intervention. The second level of cache is the sessionfactory-level cache, which is a process-wide cache.

There are also two types of L2 caches.

Built-in cache: Hibernate comes with it, it cannot be unloaded, usually in the initialization phase of Hibernate, Hibernate will put the mapping metadata and predefined SQL statements into the cache of the SessionFactory. The built-in cache is read-only.

External cache: The second-level cache is usually the external cache, which is not enabled by default in the sessionfactory, the data in the external cache is a copy of the database data, and the physical medium of the external cache can be memory or hard disk.

The structure of the Hibernate L2 cache.

2.Concurrent access policies.

transactional

Transactional) is only available in managed environments.

Provides a repeatable read transaction isolation level.

Suitable for data that is often read and rarely modified.

It prevents concurrency issues of dirty reads and non-repeatable reads.

The cache supports transactions, and the cache can also be rolled back in the event of an exception.

read-write

read-write EC) provides the read commit transaction isolation level.

Applicable in non-clustered environments.

Suitable for data that is often read and rarely modified.

Dirty reads can be prevented.

When the cache is updated, the data in the cache is locked.

nonstrict-read-write

Non-strictly read-write type).

Applies to data that is rarely modified, and occasionally dirty reads are allowed (it is rare for two transactions to modify data at the same time).

The consistency of the data in the cache and database is not guaranteed.

Set a short expiration time for cached data to minimize dirty reads.

The data in the cache is not locked.

read-only

Read-only) applies to data (such as reference data) that will never be modified

In this mode, if the data is updated, there will be an exception.

The transaction isolation level is low, and the concurrency performance is high.

Works perfectly in a clustered environment.

Analysis: Through the above ** analysis is as follows.

Ideal for placing data in L2 caches.

It is rarely modified.

Not very important data, allowing for occasional concurrency issues.

Data that is not suitable for placement in a L2 cache.

Frequently modified.

Financial data, there is absolutely no room for concurrency problems.

Data shared with other app data.

There are two main categories, 1) a place for overall use, such as setting database usernames, passwords, constants, mapping file locations, etc., and only one file can be used for the entire hibernate project;

2) Each entity mapping has a *** file, that is, the entity mapping file, which writes the mapping configuration of the database and entity classes, including relational mapping or inheritance mapping, etc.; For example, entity classes use this mapping file; So a hibernate project tends to have multiple profiles. However, these configurations can also be written in the form of annotations in entity classes.

Hibernate supports standard JPA annotations.

Implement L1 and L2 caching through require and session. SessionFactory implements additional caching.