1

We are use using Hibernate Search 3.4.2 Final and EHCACHE 2.3.1 in one of our applications. The data indexed by Hibernate Search is read-only. For performance reasons, we are loading the complete data into the second-level cache.

For some time something happens accidentally that clears the complete second-level cache. That must be something that is not explicitly triggered by our Code.

Is there anyone who has a presumption? Is there a chance that the usage of Hibernate Search inside a rollbacked transaction can lead to this behaviour?

Edit1:

This is our EHCACHE configuration:

<ehcache updateCheck="false">
    <diskStore path="java.io.tmpdir/ds42" />

    <defaultCache maxElementsInMemory="200000" eternal="true"
              statistics="true" overflowToDisk="true" diskPersistent="false"
              diskExpiryThreadIntervalSeconds="3600" memoryStoreEvictionPolicy="LRU"/>
</ehcache>
K-Menki
  • 31
  • 5
  • Could it just be the size of the cache, i.e. the data gets too big (maybe some other data in the same cache) which causes the cache to drop something? – Thomas Feb 11 '16 at 16:08
  • I'm no Hibernate Search expert but we're using it as well and AFAIK it only reads entities so it shouldn't affect the 2nd level cache. – Thomas Feb 11 '16 at 16:09
  • 1
    sounds like log forensic job – nolexa Feb 11 '16 at 16:12
  • Do you execute any DML native queries? If so, [this answer](http://stackoverflow.com/a/34418400/4754790) could be useful. – Dragan Bozanovic Feb 11 '16 at 16:17
  • May be it exceeds "tiimetoliveSeconds" it is an entry after which the cache gets cleared and it goes back to db to get the latest data Eg – user3509208 Feb 11 '16 at 16:31
  • I've added our EHCACHE configuration. – K-Menki Feb 12 '16 at 14:54
  • Hibernate Search would never invalidate the 2nd level cache, so I would suggest exploring the updates caused by actually not-rolled-back transactions of Hibernate ORM. Try to get a stacktrace from an invalidation? – Sanne Feb 12 '16 at 17:27
  • Thanks for all your tips. With the tip from @Sanne I've found this [link](https://www.link-intersystems.com/blog/2011/10/08/impact-of-native-sql-queries-on-hibernates-second-level-cache/) .This looked like a perfect mach for me, because we use native queries in some cases. So I added this: `query.unwrap(org.hibernate.SQLQuery.class).addSynchronizedQuerySpace("");` to all native queries. The problem exists anyway. – K-Menki Feb 17 '16 at 10:19
  • Ok the problem is solved. There were still some native queries without this addition. I've added `query.unwrap(org.hibernate.SQLQuery.class).addSynchronizedQuerySpace("");` and now the cache remains filled. Thanks for all your help! :) – K-Menki Feb 19 '16 at 18:45

1 Answers1

2

The answer to this "surprising" behaviour can be found inside this article.

Add

query.unwrap(org.hibernate.SQLQuery.class).addSynchronizedQuerySpace("");

to prevent Hibernate from clearing the second-level cache.

K-Menki
  • 31
  • 5