Spring Webflux and @Cacheable Annotation

1. Introduction

In this article, we’ll explain how Spring WebFlux interacts with @Cacheable annotation. First, we’ll cover some common problems and how to avoid them. Next, we’ll cover the available workarounds. Finally, as always, we’ll provide code examples.

2. @Cacheable and Reactive Types

This topic is still relatively new. At the time of writing this article, there was no fluent integration between @Cacheable and reactive frameworks. The primary issue is that there are no non-blocking cache implementations (JSR-107 cache API is blocking). Only Redis is providing a reactive driver.

Despite the issue we mentioned in the previous paragraph, we can still use @Cacheable on our service methods. This will result in caching of our wrapper objects (Mono or Flux) but won’t cache the actual result of our method.

2.1. Project Setup

Let us illustrate this with a test. Before the test, we need to set up our project. We’ll create a simple Spring WebFlux project with a reactive MongoDB driver. Instead of running MongoDB as a separate process, we’ll use Testcontainers.

Our test class will be annotated with @SpringBootTest and will contain:

final static MongoDBContainer mongoDBContainer = new MongoDBContainer(DockerImageName.parse("mongo:4.0.10"));

@DynamicPropertySource
static void mongoDbProperties(DynamicPropertyRegistry registry) {
    mongoDBContainer.start();
    registry.add("spring.data.mongodb.uri",  mongoDBContainer::getReplicaSetUrl);
}

These lines will start a MongoDB instance and pass the URI to SpringBoot to auto-configure Mongo repositories.

For this test, we’ll create ItemService class with save and getItem methods:

@Service
public class ItemService {

    private final ItemRepository repository;

    public ItemService(ItemRepository repository) {
        this.repository = repository;
    }
    @Cacheable("items")
    public Mono<Item> getItem(String id){
        return repository.findById(id);
    }
    public Mono<Item> save(Item item){
        return repository.save(item);
    }
}

In application.properties, we set loggers for cache and repository so we can monitor what is happening in our test:

logging.level.org.springframework.data.mongodb.core.ReactiveMongoTemplate=DEBUG
logging.level.org.springframework.cache=TRACE

2.2. Initial Test

After the setup, we can run our test and analyze the result:

@Test
public void givenItem_whenGetItemIsCalled_thenMonoIsCached() {
    Mono<Item> glass = itemService.save(new Item("glass", 1.00));

    String id = glass.block().get_id();

    Mono<Item> mono = itemService.getItem(id);
    Item item = mono.block();

    assertThat(item).isNotNull();
    assertThat(item.getName()).isEqualTo("glass");
    assertThat(item.getPrice()).isEqualTo(1.00);

    Mono<Item> mono2 = itemService.getItem(id);
    Item item2 = mono2.block();

    assertThat(item2).isNotNull();
    assertThat(item2.getName()).isEqualTo("glass");
    assertThat(item2.getPrice()).isEqualTo(1.00);
}

In the console, we can see this output (only essential parts are shown for brevity):

Inserting Document containing fields: [name, price, _class] in collection: item...
Computed cache key '618817a52bffe4526c60f6c0' for operation Builder[public reactor.core.publisher.Mono...
No cache entry for key '618817a52bffe4526c60f6c0' in cache(s) [items]
Computed cache key '618817a52bffe4526c60f6c0' for operation Builder[public reactor.core.publisher.Mono...
findOne using query: { "_id" : "618817a52bffe4526c60f6c0"} fields: Document{{}} for class: class com.baeldung.caching.Item in collection: item...
findOne using query: { "_id" : { "$oid" : "618817a52bffe4526c60f6c0"}} fields: {} in db.collection: test.item
Computed cache key '618817a52bffe4526c60f6c0' for operation Builder[public reactor.core.publisher.Mono...
Cache entry for key '618817a52bffe4526c60f6c0' found in cache 'items'
findOne using query: { "_id" : { "$oid" : "618817a52bffe4526c60f6c0"}} fields: {} in db.collection: test.item

On the first line, we see our insert method. After that, when getItem is called, Spring checks the cache for this item, but it’s not found, and MongoDB is visited to fetch this record. On the second getItem call, Spring again checks cache and finds an entry for that key but still goes to MongoDB to fetch this record.

This happens because Spring caches the result of the getItem method, which is the Mono wrapper object. However, for the result itself, it still needs to fetch the record from the database.

In the following sections, we’ll provide workarounds for this issue.

3. Caching the Result of Mono/Flux

Mono and Flux have a built-in caching mechanism that we can use in this situation as a workaround. As we previously said, @Cacheable caches the wrapper object, and with a built-in cache, we can create a reference to the actual result of our service method:

@Cacheable("items")
public Mono<Item> getItem_withCache(String id) {
    return repository.findById(id).cache();
}

Let’s run the test from the last chapter with this new service method. The output will look like following:

Inserting Document containing fields: [name, price, _class] in collection: item
Computed cache key '6189242609a72e0bacae1787' for operation Builder[public reactor.core.publisher.Mono...
No cache entry for key '6189242609a72e0bacae1787' in cache(s) [items]
Computed cache key '6189242609a72e0bacae1787' for operation Builder[public reactor.core.publisher.Mono...
findOne using query: { "_id" : "6189242609a72e0bacae1787"} fields: Document{{}} for class: class com.baeldung.caching.Item in collection: item
findOne using query: { "_id" : { "$oid" : "6189242609a72e0bacae1787"}} fields: {} in db.collection: test.item
Computed cache key '6189242609a72e0bacae1787' for operation Builder[public reactor.core.publisher.Mono...
Cache entry for key '6189242609a72e0bacae1787' found in cache 'items'

We can see almost similar output. Only this time, there is no additional database lookup when an item is found in the cache. With this solution, there is a potential problem when our cache expires.  Since we are using a cache of a cache, we need to set appropriate expiry times on both caches. The rule of thumb is that Flux cache TTL should be longer than @Cacheable.

4. Using Caffeine

Since Reactor 3 addon will be deprecated in the next release (starting with 3.6.0) we will use just Caffeine to show the implementation of cache. For this example, we’ll configure the Caffeine cache:

public ItemService(ItemRepository repository) {
    this.repository = repository;
    this.cache = Caffeine.newBuilder().build(this::getItem_withAddons);
}

In the ItemService constructor, we initialize the Caffeine cache with minimum configuration, and in the new service method, we use that cache:

@Cacheable("items")
public Mono<Item> getItem_withCaffeine(String id) {
    return cache.asMap().computeIfAbsent(id, k -> repository.findById(id).cast(Item.class)); 
}

When we re-run the test from before, we’ll get similar output as in the previous example.

5. Conclusion

In this article, we covered how Spring WebFlux interacts with @Cacheable. In addition, we described how they could be used and some common problems.