Hibernate кэш стратегия

Question

Как мне решить, какой CacheConcurrencyStrategy использовать?

• NonstrictReadWriteCache,
• ReadOnlyCache
• ReadWriteCache
• TransactionalCache.

Я читаю https://www.hibernate.org/hib_docs/v3/api/org/hibernate/cache/CacheConcurrencyStrategy.html,, но недостаточно подробно объясняю.

Answer 1

Документация Hibernate довольно хорошо определяет их:

19.2.2. Стратегия: только чтение

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

19.2.3. Стратегия: чтение / запись

Если приложение необходимо обновить данные, кэш для чтения-записи может быть подходящее. Это кеш стратегия никогда не должен использоваться, если сериализуем уровень изоляции транзакции требуется. Если кеш используется в JTA, вы должны указать имущество hibernate.transaction.manager_lookup_class и называя стратегию получения JTA TransactionManager. В других среды, вы должны убедиться, что транзакция завершается, когда Session.close() или Session.disconnect() называется. если ты хочу использовать эту стратегию в кластер, вы должны убедиться, что базовая реализация кеша поддерживает блокировку. Встроенный кеш провайдеры не поддерживают блокировку.

19.2.4. Стратегия: неограниченное чтение / запись

Если приложение только изредка необходимо обновить данные (т. е. если это крайне маловероятно, что два транзакции будут пытаться обновить один и тот же элемент одновременно) и строгий изоляция транзакции не требуется, кеш нестрогого чтения-записи может быть подходящее. Если кеш используется в JTA среда, вы должны указать hibernate.transaction.manager_lookup_class. В других средах вы должны убедитесь, что транзакция завершено, когда Session.close() или Session.disconnect() называется.

19.2.5. Стратегия: транзакционная

Стратегия транзакционного кэша обеспечивает поддержку полностью поставщики транзакционного кэша, такие как JBoss TreeCache. Такой кеш может только использоваться в среде JTA, и вы должен указать hibernate.transaction.manager_lookup_class.

Другими словами:

• Только для чтения: Полезно для данных, которые часто читаются, но никогда не обновляются (например, ссылочные данные, такие как страны). Это просто. У этого есть лучшие действия всех (очевидно).

• Чтение / запись: Желательно, если ваши данные требуют для обновления . Но он не обеспечивает SERIALIZABLE уровень изоляции, может происходить фантомное чтение (вы можете увидеть в конце транзакции то, чего не было в начале). Он имеет больше накладных расходов, чем только для чтения.

• Нестрогое чтение / запись: В качестве альтернативы, если маловероятно, что две отдельные потоки транзакции могут обновить один и тот же объект, вы можете использовать стратегию нестрогого чтения-записи. Это имеет меньше накладных расходов, чем чтение и запись. Это полезно для данных, которые редко обновляются .

• Транзакционный: Если вам нужен полностью транзакционный кэш. Подходит только в среде JTA.

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

Answer 2

READ_ONLY: Используется только для сущностей, которые никогда не изменяются (исключение выдается, если предпринята попытка обновить такую ​​сущность). Это очень просто и производительно. Очень подходит для некоторых статических справочных данных, которые не меняются.

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

READ_WRITE: Эта стратегия гарантирует строгую согласованность, которой она достигает, используя «мягкие» блокировки: при обновлении кэшируемого объекта в кеше также сохраняется мягкая блокировка для этого объекта, который освобождается после совершения сделки. Все одновременные транзакции, которые обращаются к программно-заблокированным записям, будут получать соответствующие данные непосредственно из базы данных.

TRANSACTIONAL: Изменения в кэше выполняются в распределенных транзакциях XA. Изменение в кэшированном объекте либо фиксируется, либо откатывается как в базе данных, так и в кэше в одной и той же транзакции XA.

Answer 3

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

Answer 4

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

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

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

4. Только для чтения - стратегия параллелизма, подходящая для данных, которая никогда не изменяется. Используйте его только для справочных данных.

Надеюсь, это очистит ваши сомнения!