Hibernate L2 cache in cluster

Q1. EhCache works very well as Hibernate L2 cache, distributed. We are using this for our project.

Q2. Multiple caches possible.

• The entire database is already doing a lot of caching internally, so don't worry about that part.

However, the problem with the database is the cache is physically on the database server, so every request includes a network call (latency, bandwith ..). That's the whole point of caches on demand server.

• The Hibernate L2 cache has some features:
  • very easy to work with (no code, little configuration)
  • conceptually at the entity level (which is quite fine-grained, we sometimes need to cache large grains, do fewer database queries),
  • works with an identifier or a collection (for example, query result caching is disabled by default, since it cannot be made useful in general).

• If Hibernate L2 is not suitable, we use the same EhCache library to cache data (these are not exactly entities). Examples of using:
  • when the table is large (length and record number) the memory usage will not allow it to be cached completely, but caching only three fields for all records is fine. Perhaps these fields are frequently available or immutable ...
  • when we have a lot of read accesses in the cache, and each of them will start a computation (in the L2 cache) given the entities we have: the result of the computation can be stored in the cache. (a typical example when the calculation requires details from other tables, but the details are not used in the final result, so the cache does not store this data).
  • when the entities in the table are logically grouped into categories , and we want to query and cache one category at a time, instead of the usual L2 cache policy, which would be one entity at a time.

In a distributed context, this often leads to invalidation at a time when one of their entities, which is functionally logical for us (and essential for since otherwise we would have to invalidate all these entities; this is due to the fact that the cache invalidates the whole region or a specific object, but in between you need to loop, which is bad for performance)

And others, I'm sure ...

So this case is not closely related to the database, it usually does not save our Hibernate objects. We put it in the business layer (not Data Access or Daos), provide it directly to the business codes. Please note that for us this is not a transparent cache, but a call to an explicit business service (responsible for this cache: loading it if no data is available, invalid if necessary) that performs operations or passes values.

An interesting issue with Threading in this cache is that since the cache has access to stoma web threads, it must be thread safe. You probably know why the thread safety value is immutable or cloned on every call (which is often a performance issue). So all of our business caches use immutable objects and the performance is excellent.