Стандартный способ обработки репозитория в JPA

Question

Рассмотрим следующий сценарий.

В db есть таблица, содержимое которой вместе образует хранилище. Эта таблица будет обновляться (обновление существующих функций, добавление новых объектов или удаление объектов) редко. Поэтому в настоящее время подход, который я использовал, заключался в создании одноэлементного pojo XXXRepository, которое будет считывать все строки (сущности) из таблицы XXX и сохранять их на карте.

Если кто-то обновляет таблицу XXX, то после выполнения части кода обновления будет запущен пост-запуск, который очистит хранилище (карту) и, следовательно, в следующий раз, когда любой объект будет найден на карте, loadRepository будет вызывается (так как карта будет нулевой).

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

Существует ли какой-либо стандартный способ, предоставляемый / поддерживаемый в JPA / Hibernate для достижения / реализации этого требования.

Я прошел через механизм кэширования (кеш 1-го и 2-го уровня). Но, похоже, это относится к сущностям, запросам или данным и для другой цели / подхода, чем то, что ожидается от Repository. Также, если нам удастся как-то этого добиться с помощью кеша 2-го уровня, то есть еще одна проблема, которая кеширует обновления только в случае операций jpa и jpql-запросов. В случае jdbc или нативных запросов обновление не удастся, и у нас будут устаревшие данные (поправьте меня, если я ошибаюсь).

Пожалуйста, помогите мне в этом, что является стандартным способом для этого в jpa.

Answer 1

Если все объекты можно хранить в памяти без проблем, тогда проблема легко решается с помощью кэша второго уровня.Каждый раз, когда вы хотите прочитать данные от нескольких из этих сущностей, вам просто нужно выполнить запрос, извлекающий все сущности, и отфильтровать результаты в Java.

Если этот уникальный запрос «извлекать все» кэшируется в кэше второго уровня, он всегда будет возвращать объекты из памяти, кроме случаев, когда выполняется обновление (в этом случае кэш второго уровня будет отбрасывать егокэшированные значения).Вы также должны поместить сами объекты в кэш второго уровня и убедиться, что кэш для этого объекта может содержать все объекты.Таким образом, вызовы session.get и навигация по связям с этой сущностью также будут использовать кэш второго уровня.

Ясно, что вы повторно реализовали то, что кэш второго уровня делает для вас.

Каким бы ни было решение, невозможно избежать возврата устаревших данных, если какой-либо процесс обновит данные за спиной Hibernate.Либо вы принимаете этот факт (и настраиваете время жизни кэша, чтобы ограничить стабильность), либо не принимаете его, и у вас нет другого выбора, кроме как запрашивать базу данных каждый раз, когда вам нужны данные.