Yichun Zhao's blog

SpringBoot Redis Cache Optional, and Configurations

Yichun Zhao's photo
Yichun Zhao
·

5 min read

   @Override
    @Cacheable(cacheNames = "errorTemplates")
    public Optional<ErrorTemplate> getErrorTemplateById(String templateId) {
        var entityOptional = errorTemplateRepository.findById(templateId);

        return entityOptional.map(this::convertErrorTemplateToDomain);
    }

Yes, you can cache the Optional<ErrorTemplate> data type using Spring's @Cacheable annotation as you have shown in your code snippet. Caching an Optional is a valid approach, especially when dealing with methods that might return an empty value indicating the absence of a value, as is common with repository methods like findById.

Here's a breakdown of how it works in your context:

  • Cacheable Method: Your method getErrorTemplateById is annotated with @Cacheable(cacheNames = "errorTemplates"). This tells Spring to cache the results of this method under the cache named "errorTemplates". The cache key will be the method parameter templateId by default, unless you specify a different key using the key attribute of the @Cacheable annotation.

  • Optional as Return Type: Using Optional<ErrorTemplate> as a return type is a good practice for methods that might not find the entity in the database. It makes the absence of a value explicit and avoids returning null.

  • Caching the Optional: When you cache an Optional, you are caching the container object itself, not the value it might or might not contain. This means that:

    • If the Optional is empty (Optional.empty()), this state is cached. Subsequent calls with the same templateId that hit the cache will return Optional.empty(), avoiding a database call.
    • If the Optional contains a value (Optional.of(someValue)), the value along with the Optional wrapper is cached. Subsequent calls with the same templateId that hit the cache will return an Optional containing the value, again avoiding a database call.

Caching an Optional is particularly useful in scenarios where the absence of a value is a common case and fetching it from the database or any other source is an expensive operation. It reduces the load on the database and speeds up the application by avoiding repeated lookups for the same missing entity.

Just ensure that your cache is properly configured to handle the serialization and deserialization of Optional instances if your cache store requires it (like when using a distributed cache). Spring's default cache abstraction usually handles this seamlessly with common cache managers.

@EnableCaching(proxyTargetClass = true)

The @EnableCaching annotation is a part of Spring Framework's cache abstraction that enables annotation-driven cache management capability in your Spring application. When you use @EnableCaching in your configuration, it triggers the search for caching annotations on Spring-managed beans in the application context, such as @Cacheable, @CacheEvict, @CachePut, etc., and enables their behavior.

The proxyTargetClass = true attribute of @EnableCaching is specifically related to how Spring creates proxies for the beans that require caching behavior (or any other aspect-oriented programming features). Here's what it means:

  • Default Behavior (proxyTargetClass = false): By default, Spring uses JDK dynamic proxies to proxy the beans that have caching annotations (or any other AOP-related annotations). JDK dynamic proxies can only proxy interfaces, not classes. Therefore, if your bean implements an interface, Spring will create a JDK dynamic proxy to intercept calls to the methods declared in the interface.

  • Proxy Target Class (proxyTargetClass = true): When you set proxyTargetClass = true, Spring will use CGLIB to create a proxy of the actual class, not just an interface the class implements. This is necessary when you want to proxy methods that are not declared on an interface or when the bean class does not implement any interfaces at all. CGLIB is capable of proxying concrete classes, allowing Spring to intercept calls to any method in the bean, not just those methods declared in an interface.

Setting proxyTargetClass = true is particularly useful when:

  • You have beans that do not implement any interfaces, yet you want to apply caching (or other AOP features) to them.
  • You want to proxy methods that are not part of an interface.

In the context of caching, using proxyTargetClass = true ensures that Spring can manage caching on any method of your beans, regardless of whether those methods are part of an interface or not. This gives you the flexibility to apply caching more broadly within your application without being constrained by the requirement to have interface-based proxies.

# ===============================
# = Redissson - Caching
# ===============================
spring.data.redis.sentinel.nodes=${REDIS_SENTINEL_HOSTS}
spring.data.redis.password=${REDIS_PWD}
spring.data.redis.sentinel.master=mymaster

#cache time unit in seconds
spring.cache.redis.cache-null-values=false
spring.cache.cache-names=InternalCustomerIdentifier,CustomerIdentityDetails,ExternalCustomerIdentifier
#format is cacheExpirations.#cacheName#
#InternalCustomerIdentifer - internalCustomerId, anonymousCustomerKey: 24 hours
spring.cache.cacheExpirations.InternalCustomerIdentifier=${INTERNAL_CUSTOMER_IDENTIFIERS_TTL:86400}
#ExternalCustomerIdentifer: 24 hours
spring.cache.cacheExpirations.ExternalCustomerIdentifier=${EXTERNAL_CUSTOMER_IDENTIFIERS_TTL:86400}
#CustomerIdentityDetails: 6 hours
spring.cache.cacheExpirations.CustomerIdentityDetails=${CUSTOMER_DETAILS_TTL:21600}

The code snippet you provided appears to be a configuration for Redis caching using the Redisson framework in a Spring application. Let me break down what each part of this configuration is doing:

  1. Redis Sentinel Configuration:

    • spring.data.redis.sentinel.nodes=${REDIS_SENTINEL_HOSTS}: This sets the Redis Sentinel nodes that the application should connect to. The ${REDIS_SENTINEL_HOSTS} likely refers to an environment variable or property that specifies the list of Redis Sentinel hosts.

    • spring.data.redis.password=${REDIS_PWD}: This sets the password for the Redis server if authentication is required. The ${REDIS_PWD} is likely a placeholder for the actual password.

    • spring.data.redis.sentinel.master=mymaster: This configures the Redis Sentinel master node that the application should use.

  2. Cache Configuration:

    • spring.cache.redis.cache-null-values=false: This configuration specifies that null values should not be cached.

    • spring.cache.cache-names: This defines the names of the caches that will be used in the application. In this case, it lists three cache names: InternalCustomerIdentifier, CustomerIdentityDetails, and ExternalCustomerIdentifier.

  3. Cache Expiration Configuration:

    • spring.cache.cacheExpirations.InternalCustomerIdentifier: This sets the expiration time (time to live) for the cache named InternalCustomerIdentifier. The value is retrieved from the ${INTERNAL_CUSTOMER_IDENTIFIERS_TTL} environment variable or property, with a default value of 86400 seconds (24 hours).

    • spring.cache.cacheExpirations.ExternalCustomerIdentifier: Similarly, this sets the expiration time for the cache named ExternalCustomerIdentifier, with a default of 86400 seconds (24 hours).

    • spring.cache.cacheExpirations.CustomerIdentityDetails: This sets the expiration time for the cache named CustomerIdentityDetails to 21600 seconds (6 hours) if the ${CUSTOMER_DETAILS_TTL} variable or property is not provided.

In summary, this configuration sets up Redis caching for specific cache names in a Spring application, with defined cache expiration times. It also configures the Redis Sentinel nodes and password for connecting to the Redis server. The actual values for cache expiration times and Redis connection details can be customized by setting the corresponding environment variables or properties.

SpringbootSpringRedis