Стратегия гибернации кэша

Question

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

• NonstrictReadWriteCache,
• ReadOnlyCache,
• ReadWriteCache,
• TransactionalCache.

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

Answer 1

Тот Самый Документация для перехода в спящий режим делает довольно хорошую работу по их определению:

19.2.2.СТРАТЕГИИ:только для чтения

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

19.2.3.СТРАТЕГИИ:чтение/ запись

Если приложению необходимо обновить данные, кэш для чтения и записи может быть подходящим.Эта стратегия кэширования никогда не должна использоваться, если она сериализуема требуется уровень изоляции транзакций .Если кэш используется в Наша среды, необходимо указать собственность 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.Такой кэш может использоваться только в среде JTA, и вы должны указать hibernate.transaction.manager_lookup_class.

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

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

• Чтение/ запись: Желательно, если ваши данные необходимы будет обновляться.Но это не обеспечивает СЕРИАЛИЗУЕМЫЙ уровень изоляции, фантом читает может произойти (вы можете увидеть в конце транзакции то, чего не было в начале).Это требует больше накладных расходов, чем доступ только для чтения.

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

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

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

Answer 2

ТОЛЬКО ДЛЯ ЧТЕНИЯ: Используется только для объектов, которые никогда не изменяются (при попытке обновить такой объект генерируется исключение).Это очень просто и эффективно.Очень подходит для некоторых статических справочных данных, которые не меняются.

НЕСТРОГОЕ ЧТЕНИЕ_WRITE: Кэш обновляется после того, как была зафиксирована транзакция, изменившая затронутые данные.Таким образом, строгая согласованность не гарантируется, и существует небольшое временное окно, в течение которого устаревшие данные могут быть получены из кэша.Такого рода стратегия подходит для вариантов использования, которые могут допускать возможную согласованность.

ЧТЕНИЕ_WRITE: Эта стратегия гарантирует надежную консистенцию, которая достигается за счет использования ‘мягких’ замков:Когда кэшированный объект обновляется, в кэше также сохраняется программная блокировка для этого объекта, которая снимается после фиксации транзакции.Все параллельные транзакции, которые обращаются к записям с программной блокировкой, будут извлекать соответствующие данные непосредственно из базы данных.

ТРАНЗАКЦИОННЫЙ: Изменения кэша производятся в распределенных транзакциях XA.Изменение в кэшированном объекте либо фиксируется, либо откатывается как в базе данных, так и в кэше в рамках одной транзакции XA.

Answer 3

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

Answer 4

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

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

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

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

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