Какие существуют стратегии использования Spring Cache для методов, которые принимают параметр array или collection?

Question

Я хочу использовать абстракцию Cache Spring, чтобы комментировать методы как @Cacheable. Однако некоторые методы предназначены для принятия массива или набора параметров и возврата коллекции. Например, рассмотрим этот метод, чтобы найти entites:

public Collection<Entity> getEntities(Collection<Long> ids) 

семантически, мне нужно кэшировать Entity объекты по отдельности (в привязке по идентификатору), а не на основе сбора идентификаторов в целом. Подобно тому, о чем спрашивает this question.

Simple Spring Memcached поддерживает то, что я хочу, через его ReadThroughMultiCache, но я хочу использовать абстракцию Spring для того, чтобы поддержать легкое изменение реализации хранилища кэша (гуава, Согласованность, Hazelcast и т.д.), а не только Memcached.

Какие существуют стратегии кэширования такого метода с использованием Spring Cache?

Answer 1

Spring's Cache Abstraction не поддерживает это поведение из коробки. Однако это не означает, что это невозможно; это немного больше работы для поддержки желаемого поведения.

Я написал небольшую example, демонстрирующую, как разработчик может это выполнить. В примере используется Spring ConcurrentMapCacheManager, чтобы продемонстрировать настройки. Этот пример должен быть адаптирован к вашему желаемому поставщику кеширования (например, Hazelcast, Coherence и т. Д.).

Короче говоря, вам необходимо переопределить метод реализации CacheManager для «украшения» Cache. Это зависит от реализации и реализации. В ConcurrentMapCacheManager способ равен createConcurrentMapCache(name:String). В Spring Data GemFire ​​вы переопределите метод getCache(name:String), чтобы украсить возвращаемый кэш. Для Гуавы это будет createGuavaCache(name:String) в GuavaCacheManager и так далее.

Тогда ваш custom, decorated Cache implementation (возможно/в идеале, делегирование фактическому Cache impl, от this) будет обрабатывать кеширование Коллекций ключей и соответствующих значений.

Есть несколько ограничений этого подхода:

1. Промах кэша это все или ничего; то есть кешированные частичные ключи будут считаться пропуском, если отсутствует какой-либо один ключ. Spring (OOTB) не позволяет одновременно возвращать значения кеша и вызывать метод для diff. Это потребует очень больших изменений в аббревиатуре Cache, которую я бы не рекомендовал.

2. Моя реализация является лишь примером, поэтому я решил не выполнять операцию Cache.putIfAbsent(key, value) (here).

3. Хотя моя реализация работает, ее можно сделать более надежной.

В любом случае, я надеюсь, что он дает некоторое представление о том, как правильно обращаться с этой ситуацией.

Испытательный класс является автономным (использует Spring JavaConfig) и может работать без каких-либо дополнительных зависимостей (за пределами Spring, JUnit и JRE).

Cheers!