Блог

Короче говоря, когда @CacheEvict вызывается в методе и если ключ для записи не найден, Gemfire выдает исключение EntryNotFoundException .

Теперь подробнее,

У меня есть класс

 class Person {

 String mobile;
 int dept;
 String name;

}
  

У меня есть две области кэша, определенные как personRegion и personByDeptRegion, и служба выглядит следующим образом

 @Service
class PersonServiceImpl {

   @Cacheable(value = "personRegion")
   public Person findByMobile(String mobile) {

      return personRepository.findByMobile(mobile);

   }


   @Cacheable(value = "personByDeptRegion")
   public List<Person> findByDept(int deptCode) {

      return personRepository.findByDept(deptCode);

   }


   @Caching(
      evict = { @CacheEvict(value = "personByDeptRegion", key="#p0.dept"},
      put = { @CachePut(value = "personRegion",key = "#p0.mobile")}

   )
   public Person updatePerson(Person p1) {

      return personRepository.save(p1);

   }

}
  

При вызове updatePerson и если в personByDeptRegion нет записей, это вызовет исключение, которое EntryNotFoundException для ключа 1 (или любого другого кода отдела). Существует очень большая вероятность того, что этот метод будет вызван до вызова методов @Cacheable, и вы хотите избежать этого исключения.
Есть ли какой-либо способ, которым мы могли бы настроить поведение Gemfire, чтобы корректно возвращать, когда ключ не существует для данного региона?.
В качестве альтернативы, я также хотел бы узнать, существует ли лучшая реализация вышеупомянутого сценария с использованием Gemfire в качестве кэша.

Источник данных Gemfire: 1.7.4

Версия Gemfire: v8.2.1

Примечание: Приведенный выше код предназначен только для представления, и у меня есть несколько сервисов с одинаковой проблемой в реальном проекте.

Во-первых, я рекомендую вам использовать аннотации кеширования Spring @Service для компонентов вашего приложения. Слишком часто разработчики включают кэширование в своих репозиториях, что, на мой взгляд, является дурным тоном, особенно если сложные бизнес-правила (или даже дополнительный ввод-вывод; например, вызов веб-службы из компонента service) задействованы до или после взаимодействия с репозиторием (ами), особенно в случаях, когда поведение кэширования не должно бытьзатронуто (или определено).

Я также думаю, что ваше кэширование UC (обновление одного кэша ( personRegion ) при одновременном аннулировании другого ( personByDeptRegion ) при обновлении хранилища данных), следуя a CachePut с a CacheEvict , кажется мне разумным. Тем не менее, я хотел бы отметить, что, по-видимому, предполагаемое использование @Caching аннотации заключается в объединении нескольких аннотаций кэширования одного и того же типа (например, множественных @CacheEvict или множественных @CachePut ), как описано в справочном руководстве core Spring Framework . Тем не менее, ничто не мешает вашему предполагаемому использованию.

Я создал аналогичный тестовый класс здесь, смоделированный по вашему примеру выше, чтобы проверить проблему. Действительно, тестовый пример jonDoeUpdateSuccessful завершается неудачно (с GemFire EntryNotFoundException , показанным ниже), поскольку ни один человек из Department «R amp; D» ранее не кэшировался в « DepartmentPeople » области GemFire до обновления, в отличие от тестового примера janeDoeUpdateSuccessful, который приводит к заполнению кэша до обновления (даже если запись не содержитзначения, что не имеет значения).

 com.gemstone.gemfire.cache.EntryNotFoundException: RESEARCH_DEVELOPMENT
    at com.gemstone.gemfire.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1435)
  

ПРИМЕЧАНИЕ: в моем тесте GemFire используется как «поставщик кэша», так и система записей (SOR).

Проблема действительно заключается в использовании ЦУР Region.destroy(ключ) в реализации GemfireCache.evict(ключ), а не, и, возможно, более подходящего Region.remove(ключ).

GemfireCache.evict(key) было реализовано с Region.destroy(key) момента создания. Однако Region.remove(key) оно не было введено до версии GemFire версии 5.0. Тем не менее, я не вижу заметной разницы между Region.destroy(key) и Region.remove(key) , кроме EntryNotFoundException брошенного by Region.destroy(key) . По сути, они оба уничтожают локальную запись (как ключ, так и значение), а также распространяют операцию на другие кэши в кластере (при условии, что используется не- LOCAL область видимости).

Итак, я подал SGF-539, чтобы изменить SDG на вызов Region.remove(key) , GemfireCache.evict(key) а не Region.destroy(key) .

Что касается обходного пути, ну, в принципе, вы можете сделать только 2 вещи:

1. Реструктурируйте свой код и использование @CacheEvict аннотации и / или…
2. Используйте condition on @CacheEvict .

К сожалению, a condition нельзя указать с использованием типа класса, что-то похожее на условие Spring (в дополнение к SpEL), но этот интерфейс предназначен для другой цели, и @CacheEvict condition атрибут , не принимает тип класса.

На данный момент у меня нет хорошего примера того, как это может работать, поэтому я продвигаюсь вперед по SGF-539.

Вы можете следить за этим тикетом для получения более подробной информации и прогресса.

Извините за неудобства.

-Джон