Только для чтения и без ограничений. Чтение и запись в кэше. Параллелизм в Hibernate.

Question

Я новичок в Hibernate и столкнулся с этими концепциями в стратегии параллелизма кэширования JPA второго уровня:

Read-Only: Used when the cache is never updated. Data like names of countries etc are suitable candidate

Non-Strict Read-Write: Data that is rarely updated.

Я не понимаю, в чем именно заключается разница между ними.

Answer 1

Дело не в частоте как таковой; речь идет об оптимизации, которую может выполнять реализация кеша. Когда уровень установлен на read-only, движок знает, что ваше приложение не собирается обновлять сущность / коллекцию, и может избежать некоторой блокировки и т. Д. Уровень non-strict read-write подробно не определен, однако он позволяет реализации сделать другое вид оптимизации, возможно, с пониженной согласованностью. В обычном режиме read-write кэш пытается оставаться в точной синхронизации с базой данных; в режиме non-strict он может открыть короткое окно, когда кеш предоставит устаревшие данные (то, чего больше нет в БД). Преимущество - это повышение производительности.

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

Answer 2

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

Для Non-Strict Read-Write вы используете эту опцию, когда обновление кешированного результата может иногда меняться.

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

Это требует дополнительных проверок и синхронизации для поставщика сохраняемости, поэтому его производительность несамый высокий (как в read-only).

Вам необходимо оценить, более ли уместно использовать read-only, когда это возможно, и перезапустить сервер, когда происходит редкое изменение словарей, или внедрить Non-Strict Read-Writeи работать с немного меньшей производительностью, но без необходимости перезапускать сервер время от времени.