Только чтение против NonRestrict Read Write in Cache Concurrency в Hibernate

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

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

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

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

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

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

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