In a third post about cache managers in spring (over a long period of time), I’d like to expand on the previous two by showing how to configure multiple cache managers that dynamically create caches.
Spring has CompositeCacheManager which, in theory, should allow using more than one cache manager. It works by asking the underlying cache managers whether they have a cache with the requested name or not. The problem with that is when you need dynamically-created caches, based on some global configuration. And that’s the common scenario, when you don’t want to manually define caches, but instead want to just add @Cacheable and have spring (and the underlying cache manager) create the cache for you with some reasonable defaults.
That’s great until you need to have more than one cache managers. For example – one for local cache and one for a distributed cache. In many cases a distributed cache is needed; however not all method calls need to be distributed – some can be local to the instance that handles it and you don’t want to burden your distributed cache with stuff that can be kept locally. Whether you can configure a distributed cache provider to designate some cache to be local, even though it’s handled by the distributed cache provider – maybe, but I don’t guarantee it will be trivial.
So, faced with that issue, I had to devise some simple mechanism of designating some caches as “distributed” and some as “local”. Using CompositeCacheManager alone would not do it, so I extended the distributed cache manager (in this case, Hazelcast, but it can be done with any provider):
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 | /** * Hazelcast cache manager that handles only cache names with a specified prefix for distributed caches */public class OptionalHazelcastCacheManager extends HazelcastCacheManager { private static final String DISTRIBUTED_CACHE_PREFIX = "d:"; public OptionalHazelcastCacheManager(HazelcastInstance hazelcast) { super(hazelcast); } @Override public Cache getCache(String name) { if (name == null || !name.startsWith(DISTRIBUTED_CACHE_PREFIX)) { return null; } return super.getCache(name); }} |
And the corresponding composite cache manager configuration:
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 | <bean id="cacheManager" class="org.springframework.cache.support.CompositeCacheManager"> <property name="cacheManagers"> <list> <bean id="hazelcastCacheManager" class="com.yourcompany.util.cache.OptionalHazelcastCacheManager"> <constructor-arg ref="hazelcast" /> </bean> <bean id="caffeineCacheManager" class="com.yourcompany.util.cache.FlexibleCaffeineCacheManager"> <property name="cacheSpecification" value="expireAfterWrite=10m"/> <property name="cacheSpecs"> <map> <entry key="statistics" value="expireAfterWrite=1h"/> </map> </property> </bean> </list> </property> </bean> |
That basically means that any cache with a name starting with d: (for “distributed”) should be handled by the distributed cache manager. Otherwise, proceed to the next cache manager (Caffeine in this case). So when you want to define a method with a cacheable result, you have to decide whether it’s @Cacheable("d:cachename") or just @Cacheable("cachename")
That’s probably one of many ways to approach that issue, but I like it for its simplicity. Caching is hard (distributed caching even more so), and while we are lucky to have Spring abstract most of that, we sometimes have to handle special cases ourselves.
Published on Java Code Geeks with permission by Bozhidar Bozhanov, partner at our JCG program. See the original article here: Using Multiple Dynamic Caches With Spring Opinions expressed by Java Code Geeks contributors are their own. |
