Menu
I generally use the @Cacheable with a cache config in my spring-boot app and set specific TTL (time to live) for each cache.
I recently inherited a spring boot app that uses @Cacheable without explicitly stating a cache manager and ttl. I will be changing it to be explicit.
But I am not able to find out what are the defaults when there is nothing explicit.
I did look at the docs but found nothing there
778
You need to create a CacheConfig file to configure the cache using Java config. Add the @Cacheable annotation and pass in the cache name.
Spring provides one concurrent hashmap as default cache, but we can override CacheManager to register external cache providers as well easily.
Caching is a part of temporary memory (RAM). It lies between the application and persistence database. It stores the recently used data that reduces the number of database hits as much as possible.
The Spring Boot framework allows the integration of various cache providers, such as EhCache, Redis, Hazelcast, Infinispan, Caffeine, etc.
The majority of the cache providers supported by Spring Boot can be adjusted using dedicated application properties. To setup TTL for both caches required by our demo application, we can use the following values: In a very simple way we set TTL of the caches for 30 minutes and their capacity to 100.
With this, @Cacheable works with the set default TTL. The above is valid, but only for spring boot 2.1.X per the docs: docs.spring.io/spring-boot/docs/current/reference/html/… Spring is pretty clear about TTL/TTI (Expiration) and Eviction policies as explained in the core Spring Framework Reference Guide here.
A cache instance is nothing more than a simple key-value container. In our case the key is created based on the input parameter and the value is the outcome of the method, but it does not have to be that simple. The cache abstraction provided by Spring allows for much more, but this is a topic for a different post.
The core caching abstraction provided by Spring resides in the spring-context module. So when using Maven, our pom.xml should contain the following dependency:
Spring is pretty clear about TTL/TTI (Expiration) and Eviction policies as explained in the core Spring Framework Reference Guide here. In other words, the "defaults" depend entirely on the underlying data store (a.k.a. caching provider) used with the Spring Boot app via the Spring Cache Abstraction.
While Arpit's solution is a nice workaround and a generic, transferable solution across different caching providers (data stores), it also cannot cover more specific expiration/eviction policies, such as the kind of action to perform when an expiration/eviction, say OVERFLOW_TO_DISK, or LOCAL_DESTROY only (such as in a Highly Available (maybe zoned based), distributed scenario), or INVALIDATE, etc.
Usually, depending on the UC, evicting "all" entries is not an acceptable option and is one of the reasons why Spring delegates this responsibility to caching provider as this capability varies highly between 1 provider to another.
In summary... definitely review the requirements for your UC and pair the appropriate caching provider with the capabilities that match your UC. Spring supports a wide variety of caching providers from Redis to Apache Geode/Pivotal GemFire to Hazelcast, etc, each with different/similar capabilities in this regard.
135
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
