How I can disable the second-level cache of some certain entities in Hibernate without changing annotations

Question

I'm using Hibernate second level cache in my application, for certain business reason I can't change the entity annotation any more.

In my project, apart from changing the Database from Hibernate, there exist also other native SQL that do not go through Hibernate. Therefore, the Hibernate second-level cache data could be stale after database being updated from native SQL. That's why I want to disable the second-level cache for certain entities (programmatically or other way than changing annotation).

Thanks in advance!

Solution 1

WARNING: As Jens Schauder noted, it is impossible to configure Ehcache to store 0 elements in memory by setting maxElementsInMemory="0" as it effectively causes opposite effect - sets unlimited size for the cache. This behaviour is not mentioned on the Hibernate Caching page but is documented on Cache Configuration page.

I have quickly reviewed the documentation and haven't found alternative approach yet. I am unable to delete this answer by myself. :-(

My original suggestion:

You can configure the implementation provider of second level cache to short TTL times and/or to store 0 entries of particular entity type.

E.g. if you are using the Ehcache, you can configure it in ehcache.xml:*

<cache
name="com.problematic.cache.EntityName"
maxElementsInMemory="0" <<== this should effectively disable caching for EntityName
overflowToDisk="false" <<== Do not overflow any entries to disk
/>

See Hibernate Caching in Ehcache documentation.

Solution 2

In Terracotta 3.1 and above, you can enable/disable Hibernate 2nd Level Caches on a per region basis, both in the configuration (statically) and at runtime, using the Terracotta Developer Console.

You can also monitor in realtime statistics about the cache and Hibernate, for individual nodes in a cluster or cluster-wide.

Terracotta is open source. For more details, check out Terracotta for Hibernate.

Comments

[Kewei Shang]

Thank you Matej, I think this is exactly the answer that I wanted! I have another issue, my ehcache.xml is placed in the class path of my runnable project while the entity class are placed in another entity project. It seems that the Hibernate only read the default cache setting from my ehcache.xml. which is: <defaultCache maxElementsInMemory="0" eternal="false" timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="false" /> Hibernate doesn't read my other entity cache settings in the ehcache.xml.

[Kewei Shang]

I think the in the <cache name="business.entity.car" maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="1800" timeToLiveSeconds="100000" overflowToDisk="false" /> , the name attribute is not correctly set so the Hibernate can't use read this setting and use the default one. What should I write in the name attribute?

[G.J]

Hibernate identifies cache for object by its entity name. By default class name is used as entity name, but it can be changed in Hibernate mapping files (or annotations). If you haven't changed the entity name in Hibernate mapping, you should simply use the fully qualified class name. Otherwise use the (symbolic) entity name explicitly specified in Hibernate mapping.

[Kewei Shang]

Thank you, you are exactly right. I think the defaultCache element in ehcache.xml is also used for ALL THE QueryCaches too, if I don't set the standardQueryCache element. So it's not important whether or not I set the maxElementsInMemory of <cache name="business.entity.car"...> to "0", because all the QueryCache are using the defaultCache region. Do you know by anychance How could I disable the second-level cache for some specific entity in the QueryCache (which means to disable the QueryCache in the Entity level)?

[Jens Schauder]

according to the documentation setting maxElementsInMemory to 0 interpreted as unlimited, so it would actually have the opposite effect then you want. The best suggestion I can make is to set it to 1 and to real short expire times (1 as well). Note that 0 on the expiration times is interpreted as never as well.

[G.J]

Good point, Jens. I am going to delete my answer as it is incorrect, misleading, and I do not know alternative approach.