The Implement of Cache in Hibernate

Hibernate Cache

The cache of Hibernate is mainly implemented in the net. sf. hibernate. cache package. For specific code, see the Hibernate source code.

1. Cache
This interface defines some basic cache operations, such as get, put, lock, and unlock. Based on this interface, Hibernate uses JCS and other mechanisms to implement caching, including JCSCache, OSCache, SwarmCache, TreeCache, and HashtableCache. Since the entire cache system is basically a policy mode, we will only use JCSCache as an example later. Other methods can be used in the same way.

2. CacheProvider
This interface provides the Cache configuration method: buildCache, And the timestamp method: nextTimestamp. The rule mode is also used here. For buildCache, the implementation methods of JCSCacheProvider and OSCacheProvider are different. JCSCacheProvider only generates a JCSCache instance, while OSCacheProvider also performs some other processing. Let's take a look at nextTimestamp. JCSCacheProvider directly calls the Timestamper class to generate a timestamp. In this way, the timestamp is not used by SwarmCacheProvider, But it directly returns a value with no accuracy higher than JCSCacheProvider, but the speed is fast.

3. Timestamper
This class provides a method to generate a timestamp, and its next method returns an incremental timestamp, the timestamp generated is not repeated within 1/4000 ms.

4. CacheConcurrencyStrategy
This interface defines the Cache operation policy (in fact, this is not a rule mode, it should be regarded as a proxy mode), such as ReadWriteCache and ReadOnlyCache. For the proxy mode or policy mode, we can see from the factory class CacheFactory that the -- createCache method returns the CacheConcurrencyStrategy type instead of the Cache type. However, the proxy mode here is a little different from the standard GoF mode: if the standard proxy mode is adopted, CacheConcurrencyStrategy should inherit the Cache, but here the two interfaces are processed separately.

5. Secondary lock
The CacheConcurrencyStrategy interface defines an empty interface: SoftLock. This interface does not have any method, and its function is to leave space for implementing the second-level lock. Cache systems such as JCS provide lock and unlock to lock and unlock objects. However, sometimes it is not enough to implement a simple lock operation. Some conditions need to be added, such as timestamp identification.
First, let's take a look at the case of no second-level lock. For the NonstrictReadWriteCache class, it implements the CacheConcurrencyStrategy interface, and its policy is not to use the lock. Therefore, the lock method in it is actually nothing, only "return null ;".

Next, let's take a look at the ReadWriteCache class. The policy implemented by this class is to use both the locks provided by the Cache and their own second-level locks to determine the timestamp. To implement this policy, the class also defines the following interfaces and classes:
Public static interface Lockable {...}
Public static final class Item implements Serializable, Lockable {...}
Public static final class Lock implements Serializable, Lockable, SoftLock {...}
These classes and interfaces are the core of implementing level-2 locks:
The Lockable interface is also a policy-it indicates the method in which to read and write the locked objects;
The Item class implements Lockable, which encapsulates the objects stored in the cache and the timestamp of the object, and implements the read-only lock of the object. For details, refer to the three methods of its implemented Lockable interface.

Public boolean isLock (){
// Flag. false indicates that this is not a lock but a data object.
// (The data object refers to the entity object in the cache, rather than the Lock Object)
Return false;
}
/**//**
* Is this item visible to the timestamped
* Transaction?
*/
Public boolean isGettable (long txTimestamp ){
// This shows the policy, that is, the object is related to the timestamp.
Return freshTimestamp <txTimestamp;
}

/**//**
* Don't overwite already cached items
*/
Public boolean isPuttable (long txTimestamp ){
// We really cocould refresh the item if it
// Is not a lock, but it might be slower
// Return freshTimestamp <txTimestamp
// Write operations are not allowed for read-only locks.
Return false;
}

Here we can see that the Item object can only be read but cannot be written.
The Lock object is only a Lock object, not a data object. It serves as a Lock and has no special significance for the client.

6. UpdateTimestampsCache
This class is used to track cache timestamp updates. This class has not been completed, so it is not necessary for the moment.