Why is Hibernate trying to β€œcache” and how does it work in a clustered environment?

Suppose you have a cluster of node J2EE application servers, all running instances of the Hibernate application. How does caching work in this situation? Is that generally good? Should you just turn it off?

It seems to me that the data for one particular node quickly becomes outdated, as other users hitting other nodes make changes to the database data. In a situation like Hibernate ever believed its cache was updated?

+4
source share
2 answers

First of all, Hibernate has 2 caches. There is a first level cache that you cannot delete and is called a Hibernate session. Then there is a second level cache, which is optional and pluggable (for example, Ehcache). It works on many requests and most likely the cache you are referring to.

If you are working in a cluster environment, you need a second-level cache that can replicate changes through cluster members. Ehcache can do this. Caching is a complex topic, and you need a deep understanding to use it without introducing any other problems. Caching in a clustered environment is somewhat more complicated.

+3
source

First of all, you should clarify in which cache you say that Hibernate has 3 of them (first level cache, for example, session cache, second level cache, global cache and request cache, which relies on the second -level cache). I assume this is a second level cache, so I'm going to do it.

How does caching work in this situation?

If you want to cache read-only data, there is no particular problem. If you want to cache read / write data, you need to implement a cached cache (via invalidation or replication).

Is it good?

It depends on many things: cache implementation, refresh rate, granularity of cache areas, etc.

Should you just turn it off?

Second-level caching is actually disabled by default. Turn it on if which you want to use.

It seems to me that the data on one particular node is quickly becoming obsolete, as other users hitting other nodes make changes to the database data.

This is why you need a cached cache implementation.

In such a situation, how can Hibernate believe that its cache is updated?

Simple: Hibernate trusts a cache implementation that should provide a mechanism to ensure that the node data cache is not expired. The most common mechanism is synchronous invalidity : when an object is updated, the updated cache sends a notification to other members of the cluster, informing them that the object has been changed. After receiving this message, other nodes will delete this data from their local cache, if they are stored there.

+6
source

All Articles