Spring @Cacheable default TTL

Question

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 b

Answer 1

Actually, there is a better way than using @schedule, by extending the cacheManager which defines the ttl: Here is an example :

@Configuration
public class CacheConfig extends CachingConfigurerSupport {

@Value( "${redis.hostname}" )
private String redisHostName;

@Value( "${redis.port}" )
private int redisPort;

@Value("#{${redis.ttl}}")
private int DEFAULT_TTL;


@Bean
public JedisConnectionFactory redisConnectionFactory() {
    JedisConnectionFactory redisConnectionFactory = new JedisConnectionFactory();
    redisConnectionFactory.setHostName(redisHostName);
    redisConnectionFactory.setPort(redisPort);
    return redisConnectionFactory;
}

@Bean
public RedisTemplate<String, String> redisTemplate(RedisConnectionFactory cf) {
    RedisTemplate<String, String> redisTemplate = new RedisTemplate<String, String>();
    redisTemplate.setConnectionFactory(cf);
    return redisTemplate;
}

@Bean
public CacheManager cacheManager(RedisTemplate redisTemplate) {
    RedisCacheManager cacheManager = new RedisCacheManager(redisTemplate);
    cacheManager.setDefaultExpiration(DEFAULT_TTL);
    return cacheManager;
}
}

pom dependency :

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
    <version>1.4.7.RELEASE</version>
</dependency>

Answer 2

Spring @Cacheable does not have any configurable option to set TTL for the cache though you can build it using @CacheEvict and @Scheduled, as follows:

@CacheEvict(allEntries = true, cacheNames = { "cache_1", "cache_2" })
@Scheduled(fixedDelay = 30000)
public void cacheEvict() {
}

You can find detailed solution/explanation here - Setting TTL for @Cacheable – Spring.

Answer 3

The cache will never expire by default. If we need to set expire time we have to use the below properites key. If the value will is the 10000ms, the cache will expire after 1 minute.

# Entry expiration. By default, the entries never expire.
spring.cache.redis.time-to-live=10000ms

Answer 4

With spring boot, I was able to achieve success with this:

First, you need to add spring-boot-starter-data-redis artifact to your POM file.

<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-data-redis</artifactId> 
</dependency>

After this, you need to add the required the following configurations in your application.properties files:

#------ Redis Properties -------------
spring.cache.type=redis
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.cache.redis.time-to-live=600000

The property to set is spring.cache.redis.time-to-live (value is in milliseconds. 10 mins was set in this case). With this, @Cacheable works with the set default TTL.

Answer 5

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.