Hibernate Cache Integration IMDG

1third-party cache plug-ins

In addition to this lightweight caching scheme for Ehcache , almost all IMDG products provide direct support for Hibernate level Two caches, often with:

? hazelcast

? gridgain

? JBoss Infinispan

? Terracotta ( additional integration for direct replacement Session objects )

2caching the work process

The following is an example of JVM cluster Terracotta , first from the most primitive JDBC to hibernate to the hibernate level two cache. Take a look at how the application applies to database requests.

2.1Auto-commit modeJDBC

When jdbc is used in autocommit mode,jdbc does not cache any requests, and each SQL operation is sent directly to the database. As a result, access to three users results in 9 database accesses.

2.2 HibernateCache Level

hibernate refer to various hibernate for review , By default, the second-level cache is not turned on, and you will see the resulting problem later. So by default, hibernate turns on transactions, caches update operations, and updates to the database together with the last transaction commit. commit transaction commits, altogether is 6 secondary database access. The first-level cache is automatically cleared when the session is off, or the app clears an object by evict () , clear () clears all cached content, flush () synchronizes the cache with the database. Also, the same note as the level two cache is that the uses hql or sql to query the property-level data, is not using the cached . ( the third part of how caching works in detail

2.3IntegratedHibernateLevel Two cache

Hibernate the level two cache further caches the data load requests for more than one Session . However, the risk comes with the fact that Hibernate does not request the database every time when the level two cache is turned on, so the data in the cache may be outdated. Sometimes we can use the TTL setting to force Hibernate refreshes, but in some scenarios this scenario is not feasible. At this point, you can use Terracotta to form a cluster of these level two caches,Terracotta responsible for synchronizing data between cluster nodes. This approach only changes the hibernate configuration file, but due to hibernate 's use of the two-level cache, this integration does not maximize the power of Terracotta .

2.4IntegratedHibernate Session

Terracotta The quickest way to integrate with hibernate is to integrate directly with hibernate 's Session object. Because the POJO object is actually stored as a byte array in Hibernate 's Level two cache, there is a serialization overhead, although it is already in the cache. With this integrated Hibernate Session , the application code can directly access the in-memory POJO object with zero latency, without any extra overhead. Similarly, we are able to write POJO objects in memory at 0 latency. At this point, the database becomes the history of the system and is updated only when it is needed.

3how the cache works internally3.1Level Two cache

A level two cache is called becauseHibernate automatically opens a first-level cache for you when you open the session . This is described in the official documentation for level two caches:

a Hibernate Session is A transaction-level cache of persistent data. It is possible to configure a cluster or Jvm-level (sessionfactory-level) cache on a class-by-class and Collection-by-coll Ection basis. Even plug in a clustered cache. Be careful. Caches is never aware of changes made to the persistent store by another application (though they could be configured to re gularly expire cached data).

As mentioned above, the level two cache exists as long as the sessionfactory is open. The secondary cache holds all the attributes and associations for each entity marked as cached. Let's take the person entity as an example of how the two-level cache works internally:

person object is saved in the following format: key is id , Span lang= "en-US" >value is firstname , middleinitial , Span lang= "en-US" >lastname three x string , plus parent id . So it is obvious that an instance of an object is not stored directly in the cache, but instead is split into attributes, hibernate to call this process an object dehydration (dehydrate) , whereas the process by which properties are assembled into objects is called water replenishment (hydrate) . hibernate Why did you do this?

? user code modifications on an instance of an entity do not break the cache because the cache is a copy of the instance properties.

? The association between objects is not easy to expire, even if it is expired, just update an ID , because the cache does not directly save the parent person instance that corresponds to the parents variable, but only its ID.

When the cache is not turned on and the associated cache is not turned on, the underlying SQL performed by the ID load operation is as follows. As you can see, if you do not turn on the associated cache, the SQL executed is almost the same as not opening the cache ( only the first SQL that queries the parent person is omitted ):

Now turn on the correlation cache to see how it works. When the association cache is turned on, the person's cache format is as follows. The cached content has a collection of IDs for the child person object , similar to the parent person cache, and only the ID is saved, not all child person instances. At this point, the person object itself and the nested parent (person) and Children (set<person>) are completely dehydrated into attributes and association IDs:

person object is passed id load operation does not require access to the database at all , so be sure to turn on the association cache to really play out the effect of level two cache. However, a level two cache is still not used when executing hql or sql queries. For example, when we hql query via hibernate The executes a sql with the same where condition acquires person The id , with id to start using content from the level two cache, which means: id queries, and is invalidated for other complex conditional queries . And this query id the same where condition sql is where the query cache can be useful , which leads to query caching.

3.2Query Cache

The first thing to configure is to turn on query caching

<property name= "Hibernate.cache.use_query_cache" >true</property>

Also , call Setcacheable (True)before using the Query object.

The query cache is also a form of Key-value , whose key is HQL or SQL and parameters, and value is the collection of IDs for the query result, so its value is very similar to the level two cache after the associated cache is turned on. Therefore, query caching is only useful if HQL or SQL is consistent, and the query parameters are exactly the same! now look at the effect of two caches coexisting. When the level two cache's associated cache and query cache are turned on, when we execute a specific parameter of the Hql/sql, we first go to the query cache to find the corresponding ID, and then go to the level two cache to find these objects, And the collection of objects associated with those objects .

3.3Summary

Both the level two cache and the query cache are essentially saved in key-value form, so you can only match queries against the key (id or hql/sql+ parameter ) . From this point of view, theHibernate cache is not flexible enough to actually cache objects in memory and provide object-oriented queries, as IMDG products do . Understanding the underlying workings of the hibernate cache to better manage our cached data and understand the behavior of hibernate caches.

References

1 theDefinitiveguide to Terracotta

2 Hibernate:truly Understanding the Second-level and Query Caches

Hibernate Cache Integration IMDG