3

I understood that L2 cache can't update itself if any update happens in the persistent store. So, Should I call evict2ndLevelCache() method after every write or update methods at DAO layer? Or there is a better strategy?

http://howtodoinjava.com/2013/07/02/how-hibernate-second-level-cache-works/

If some user or process make changes directly in database, the there is no way that second level cache update itself until “timeToLiveSeconds” duration has passed for that cache region. In this case, it is good idea to invalidate whole cache and let hibernate build its cache once again. You can use below code snippet to invalidate whole hibernate second level cache.

Forkmohit
  • 733
  • 3
  • 12
  • 31
  • Possible duplicate of [Hibernate 2nd level cache invalidation when another process modifies the database](http://stackoverflow.com/questions/1603846/hibernate-2nd-level-cache-invalidation-when-another-process-modifies-the-databas) – Tarik Dec 22 '15 at 08:59
  • Hi, the link also provides a sample eviction method. I was concerned for its use? So am I correct in my understanding that every update method is followed by a call to evict method? – Forkmohit Dec 22 '15 at 09:04

1 Answers1

5

If you are doing changes in Hibernate entities itself, you don't have to do anything else to ensure the consistency of L2 cache, Hibernate will take care of it.

If you are doing changes via native queries, then explicitly mention which entities are affected, otherwise Hibernate will invalidate the entire second-level cache, as explained here.

If you are changing data in the database from another process, then Hibernate is not aware of it, and you will have to define a strategy that best suits your requirements (expiration policies, explicit invalidation called from the outside of the application, etc).

Community
  • 1
  • 1
Dragan Bozanovic
  • 23,102
  • 5
  • 43
  • 110