Короткий ответ: НЕТ. не совсем.
Я также не совсем уверен, что ваше следующее утверждение полностью верно ...
Наш опыт работы с Guava (или Hazelcast, redis и т. Д.) Показывает, что нам не нужно явно определять кеши.
Что касается Hazelcast, я знаю, что это неверно из недавний опыт (см. конфигурация и, в частности, эта строка). Строка 78 абсолютно необходима (в той или иной форме, например, в качестве альтернативы XML); без него Spring Cache Abstraction вызовет исключение.
Хотя я не тестировал Redis в качестве поставщика кэширования, похоже, что Redis может обрабатывать динамическое Cache создание (также это).
Вполне вероятно, что Guava, как и ConcurrentMapCacheManager, не требует уже существующего _ 3_ будет явно определен, поскольку ConcurrentMapCacheManager будет динамически создавать Cache (a ConcurrentHashMap) во время выполнения по запросу если НЕ "названо" явно. Однако, если Caches явно названы заранее, то будет сгенерировано исключение, если Cache еще не определен (то есть «назван»).
У меня есть примеры и тесты других провайдеров кеширования здесь, которые иллюстрируют различные и довольно уникальные UC Spring Cache Abstraction на практике, идентифицируемые по именам тестового класса или тестового примера.
Однако во всех тестовых примерах Pivotal GemFire или Apache Geode необходимо явно создать регион, который будет служить «Cache» в инфраструктуре кэширования Spring. Хотя реализация SDG GemfireCacheManager будет динамически создать объект Spring Cache (поддерживаемый базовым регионом), который требуется для Spring AOP CacheInterceptor.
В результате получается следующая минимальная необходимая конфигурация для включения кэширования с использованием GemFire / Geode в качестве поставщика ...
@SpringBootApplication
@EnableCaching
class MyCachingApplication {
public static void main(String[] args) {
SpringApplication.run(MyCachingApplication.class, args);
}
@Bean
GemfireCacheManager cacheManager(GemFireCache gemfireCache) {
GemfireCacheManager cacheManager = new GemfireCacheManager();
cacheManager.setCache(gemfireCache);
return cacheManager;
}
// define all Region beans required by the application including Regions
// used specifically in Spring's Cache Abstraction
}
Теперь, сказав это, я создал прототип динамического создания региона на основе аннотаций Spring Cache Abstraction (например, @Cacheable), используемых во всех объявленных компонентах приложения [службы], как можно увидеть, начиная с этого test. Вот конфигурация.
Как видите, НЕТ явных определений bean-компонентов для регионов GemFire, которые будут служить Caches в инфраструктуре кэширования Spring. Тем не менее, компонент Spring @Service приложения (теста) делает использовать кеширование.
Создание динамической области выполняется с помощью Spring _ 17_ (здесь) и функции GemFire (с использованием поддержки аннотаций функций SDG) для динамического создания регионов во время выполнения, во время запуска. Выполнение функции: определен здесь, а фактическая реализация функции - определено здесь.
Этот пример довольно грубый (т.е. не обрабатывает настраиваемую конфигурацию региона (например, исключение / истечение срока, сохранение, переполнение и т. Д.) За пределами DataPolicy) и в настоящее время настроен для обработки топологии однорангового кеша (т.е. тестовое приложение является одноранговым членом / узлом в GemFire DS).
Однако довольно легко расширить этот прототип для использования в топологии клиент / сервер, учесть все аннотации кеширования Spring и JSR-107 и разрешить больше настраиваемых областей конфигурация.
Со временем это, возможно, я добавлю к самой структуре ЦУР.
Надеюсь это поможет.
Привет, Джон
person
John Blum
schedule
06.09.2016
