Запрос возвращает неправильные значения после запроса обновления на Jhipster Java Back service

#java #postgresql #hibernate #jhipster #ehcache

Вопрос:

В моем приложении, в моем бэкэнде Java, я вызываю с помощью SOAP UI службу для извлечения значений (ВЫБОРА), которые я получаю.

Затем я делаю обновление, которое влияет на предыдущий результат.

Затем в пользовательском интерфейсе SOAP я снова вызываю свою службу с тем же запросом ВЫБОРА, чтобы просмотреть мои изменения, но результат тот же, что и при первом вызове, мои изменения не возвращаются. Я проверяю базу данных, мои изменения присутствуют.

Мое приложение находится в JHIPSTER 7.1, а моя база данных-в Postgres. Я использую ehcache с гибернацией, и я подозреваю, что причиной этой проблемы является кэш, потому что, как только я перезапускаю свою службу, запрос возвращает правильные значения.

Знаете ли вы, почему я вижу эту проблему и как ее решить?

ПРАВКА 1

Конфигурация Ehcache

 jpa:
    open-in-view: false
    properties:
      ...
      hibernate.cache.use_second_level_cache: false <- change from true (KO) to false (OK)
      hibernate.cache.use_query_cache: false
 

Конец для профилей

Dev (текущий профиль с проблемой)

 jhipster:
  cache: # Cache configuration
    ehcache: # Ehcache configuration
      time-to-live-seconds: 3600 # By default objects stay 1 hour in the cache
      max-entries: 100 # Number of objects in each cache entry
 

Подгонять

 jhipster:
  http:
    cache: # Used by the CachingHttpHeadersFilter
      timeToLiveInDays: 1461
  cache: # Cache configuration
    ehcache: # Ehcache configuration
      time-to-live-seconds: 3600 # By default objects stay 1 hour in the cache
      max-entries: 1000 # Number of objects in each cache entry
 

Все мои запросы подписываются с помощью API RESP. Я новичок в ehcache, и в своем коде я не размещаю никакого кода об этом в своих различных сервисах …

ПРАВКА 2

Пример использования JPA в моем репозитории введите описание изображения здесь

Комментарии:

1. Похоже на проблему с кэшированием, но, не зная больше и особенно не видя какой-то код, это все, что я могу сказать. Вы можете попытаться отключить кэш или посмотреть, как сделать ваше обновление недействительным или напрямую обновить его.

2. Да, я отключил его с hibernate.cache.use_second_level_cache помощью параметра от true до false. По сути, проблема исчезла … Но я не знаю, почему. Я добавил конфигурацию в свой вопрос, что вам еще нужно, чтобы помочь мне ? У меня также есть параметр hibernate.cache.use_query_cache , который был «ложным». Это нормально ?

3. Да, отключение кэша запросов было бы нормальным. Вам следует ознакомиться с этими кэшами и другими компонентами, чтобы понять, что они делают, но вкратце: а) кэш запросов кэширует результат запроса, чтобы вернуть его при повторном выполнении той же инструкции с теми же параметрами. б) кэш 2-го уровня кэширует объекты, выходящие за рамки сеанса гибернации (часто привязанного к транзакции), который будет 1-м уровнем. Поэтому, если у вас есть метод, который фактически ищет объект по идентификатору, он может получить его со 2-го уровня вместо запроса базы данных. …

4. кэш 2-го уровня может помочь во многих ситуациях, если вы знаете, что делаете, но вам также нужно убедиться, что он обновлен. Hibernate может позаботиться об этом, если вы обновляете объекты в коде и позволяете Hibernate обновлять базу данных, но если вы используете запросы на обновление, он не будет знать, какие объекты затронуты, и в этом случае вам решать обновить или аннулировать кэш 2-го уровня.

Ответ №1:

Как вы обновляете базу данных? Использование хранилища данных Spring? Обычно, когда таблица обновляется, Hibernate очищает кэш для этой таблицы. Так что все должно быть синхронизировано.

Это не будет иметь места, если вы обновляетесь вне режима гибернации. Кроме того, посмотрите на свою стратегию кэширования для сущности. Ожидается, что объект только для чтения не изменится, поэтому Hibernate не будет удален.

Комментарии:

1. Все запросы на обновление выполняются с помощью hibernate с классом репозитория JPA, нет «пользовательского» запроса на создание или обновление данных. (пример в ПРАВКЕ 2). Когда я создаю или обновляю Saison, я использую этот репозиторий с объектом

2. Так что, вероятно, это связано со стратегией, используемой на каком-то уровне конфигурации. Которые предотвращают выселение. Поместите журнал гибернации в отладку или трассировку, это должно дать вам представление