0

I am using redisson-hibernate as Hibernate 2nd level Cache provider. If redis server becomes unavailable, while the application is running, the whole application goes down. I am trying to find a way to circuit-break the L2 cache in such a scenario.

In case redis is unavailable, hibernate should work as if L2 is disabled, and there should be some mechanism (or subsequent requests), which should check for redis availability after a specified amount of L2, and re-enables L2. Is there already a way to do this?

If not, how can I build such a mechanism? I could try running a quartz job, which checks for redis connectivity, kills and restarts the application by modifying the app config. But this approach is complicated and not very clean. Please suggest.

Aayush
  • 83
  • 1
  • 5

2 Answers2

1

I had tried the scenario which you have mentioned in a SPRING BOOT application and all the requests (HTTP) started to pile up when I shutdown Redis. But, when I re-start Redis, the application is able to reconnect and processes as usual.

Hibernate & Redis connections load up based on the configuration available in the "application.properties" file.

spring.jpa.properties.hibernate.cache.auto_evict_collection_cache=false
spring.jpa.properties.hibernate.generate_statistics=false
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.cache.use_query_cache=true
spring.jpa.properties.hibernate.javax.cache.missing_cache_strategy=create
spring.jpa.properties.hibernate.cache.redisson.config=redisson.json
spring.jpa.properties.javax.persistence.sharedCache.mode=ENABLE_SELECTIVE

I couldn't find any parameters w.r.t Hibernate / Spring JPA in Hibernate or Spring docs which could automatically detect when L2 is down.

I am also eagerly awaiting for such mechanisms in Hibernate / Spring JPA as this scenario is valid test case which will we surely face mostly in LOAD/PROD environments.

suraj vijayakumar
  • 47
  • 1
  • 4
  • I will try with Redis clustering / Sentinel configuration and let you know. If you had tried this, please do let me know. – suraj vijayakumar Dec 18 '19 at 10:39
  • I couldn't find a way to do this. I needed a failover to database, while redis was down. Seems like hibernate doesn't support this. I ended by ditching L2 and using a custom managed cache layer, using redis with guava-cache interface. – Aayush Jul 31 '20 at 09:14
  • Yes. But I have later on found that Apache Ignite has better clustering and failover mechanisms. It integrates seamlessly with Hibernate and Spring. – suraj vijayakumar Aug 14 '20 at 10:59
0

A bit late here but I also face same sort of problems with hibernate and l2 cache management / eviction with any sub jcache api (caffeine, ehcache, hazelcast, infinispan, redisson....).

we have a very small database with 99,999% read and maybe once or twice a week one write. we cache everything (entitis, queries, collections).

I tried many ways to make hibernate l2 cache auto evict entries :

  • based on sub cache configuration size or time based eviction
  • based on a custom scheduled task which tries to evict jpa cache, based on hibernate interceptors to evict chirurgically entities at max scheduled times
  • tried with debezium to evict the cache on database level update detection....

I always face from time to time a failed to load entity with id xxx... Tried many configurations, many java annotations (jpa or hibernate level), still struggling to find a working way of expiring the cache and make jpa/hibernate fallback to request directly to the database....

The only way I was able to barely fix this was by disabling hibernate query cache and create a spring cache for this (for every JpaRepo methods with aspect and custom implementation _(--)'/ )... This with Debezium to evict only updated entities (from inside or outside the app scope) were the only working scenarios. => my cached queries and entities get quickly retrieved when in cache (spring and hibernate) and chirurgical eviction of entities in the debezium callback method make any databases modification immediately reflected in the application (all servers listen to debezium , get notified and expire their local cache).

This is frustrating as this is certainly a really common scenario in prod environment...

Cottenceau Arnaud
  • 1