Switching Spring Boot Cache from EhCache to Redis for Strong Consistency

Previously we introduced two in‑process cache options used by Spring Boot: ConcurrentMapCache and EhCache. While EhCache works for many scenarios, it is a local cache and in a cluster each server has its own copy, leading to possible cache inconsistency. Even with EhCache’s synchronization strategy, a short window of inconsistency remains.

For systems that require strong consistency, a centralized cache such as Redis is a better solution. The following tutorial shows how to switch the Spring Boot caching support from EhCache to Redis.

Hands‑on

We start from the previous project. The key elements are:

User entity definition

@Entity
@Data
@NoArgsConstructor
public class User implements Serializable {
    @Id
    @GeneratedValue
    private Long id;
    private String name;
    private Integer age;
    public User(String name, Integer age) {
        this.name = name;
        this.age = age;
    }
}

User repository with cache annotations

@CacheConfig(cacheNames = "users")
public interface UserRepository extends JpaRepository<User, Long> {
    @Cacheable
    User findByName(String name);
}

Step 1 – Add dependencies

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

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-pool2</artifactId>
</dependency>

In early Spring Boot 1.x the starter was named spring-boot-starter-redis .

Step 2 – Configure Redis connection

spring.redis.host=localhost
spring.redis.port=6379
spring.redis.lettuce.pool.max-idle=8
spring.redis.lettuce.pool.max-active=8
spring.redis.lettuce.pool.max-wait=-1ms
spring.redis.lettuce.pool.min-idle=0
spring.redis.lettuce.shutdown-timeout=100ms

In Spring Boot 1.x the prefix was spring.redis.pool and the pool implementation was Jedis. Spring Boot 2.x uses Lettuce as the default client. Production settings should be tuned according to the deployment environment.

Now run a simple unit test:

@Slf4j
@RunWith(SpringRunner.class)
@SpringBootTest
public class Chapter54ApplicationTests {

    @Autowired
    private UserRepository userRepository;

    @Autowired
    private CacheManager cacheManager;

    @Test
    public void test() throws Exception {
        System.out.println("CacheManager type : " + cacheManager.getClass());

        // create a record
        userRepository.save(new User("AAA", 10));

        User u1 = userRepository.findByName("AAA");
        System.out.println("First query: " + u1.getAge());

        User u2 = userRepository.findByName("AAA");
        System.out.println("Second query: " + u2.getAge());
    }
}

Running the test produces output similar to:

CacheManager type : class org.springframework.data.redis.cache.RedisCacheManager
... (Hibernate logs) ...
First query: 10
Second query: 10

Observations:

The CacheManager is now RedisCacheManager instead of EhCacheCacheManager.

The second query does not trigger an SQL statement, confirming that the result was retrieved from Redis.

Integration succeeded!

Thought question

Given that in‑process caches like EhCache have consistency issues while Redis offers both performance and consistency, why should we still learn about local caches? Share your thoughts; we will discuss in the next article.

Code examples are available in the chapter5-4 directory of the repository:

GitHub: https://github.com/dyc87112/SpringBoot-Learning/

Gitee: https://gitee.com/didispace/SpringBoot-Learning/