This section mainly introduces the concurrent access strategy of Hibernate L2 cache and four commonly used plug-ins.
Concurrent Access Strategy for Second Level Cache
When two concurrent transactions access the same data in the persistence layer cache at the same time, various concurrency problems may occur, so necessary isolation measures need to be taken to solve these problems.
Since concurrency problems also occur in the second-level cache, in Hibernate's second-level cache, the following four types of concurrent access strategies can be set to solve these problems. Each access strategy corresponds to a transaction isolation level, which is described in detail as follows:
1) Read-Only (Read-Only)
Provides the Serializable transaction isolation level, which can be used for data that will never be modified.
2) Read-write (Read-write)
Provides the Read Committed transaction isolation level. For data that is frequently read but rarely modified, this isolation type can be used because it can prevent dirty reads.
3) Nonstrict read and write (Nonstrict-read-write)
The consistency of the data in the cache and the database is not guaranteed, and the Read Uncommitted transaction isolation level is provided. This strategy can be used for data that is rarely modified and allows dirty reads.
4) Transactional
Used only in managed environments, it provides the Repeatable Read transaction isolation level. For data that is frequently read but rarely modified, this type of isolation can be used because it prevents dirty reads and non-repeatable reads.
Common plugins for the second-level cache
The Hibernate L2 cache needs to be configured with a plugin for the L2 cache before it can be used normally. There are four commonly used plugins, as follows:
1）EHCache
It can be used as a process-wide cache, and the physical medium for storing data can be memory or hard disk. It provides support for Hibernate's query cache.
2）OpenSymphony OSCache
It can be used as a process-wide cache, and the physical medium for storing data can be memory or hard disk; it provides a wealth of cache data expiration strategies, and provides support for Hibernate's query cache.
3）SwarmCache
Can be used as a cluster-wide cache, but does not support Hibernate's query cache.
4）JBossCache
Can be used as a cluster-wide cache, supporting Hibernate's query cache.
The concurrent access strategies supported by the above four cache plug-ins are shown in Table 1 (√ means support).
| Common plugins for the second-level cache | read-only | non-strict read-write | read-write | Transactional |
|---|---|---|---|---|
| EHCache | √ | √ | √ | |
| OSCache | √ | √ | √ | |
| SwarmCache | √ | √ | ||
| JBossCache | √ | √ |
In Hibernate, not all data are suitable to be placed in the second-level cache. Generally, data that is rarely modified, unimportant and will not be accessed concurrently can be placed in the second-level cache.