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
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.