Стратегия кэширования Hibernate

Ответ 1

Hibernate documentation неплохо справляется с их определением:

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, phantom читает (вы можете увидеть в конце транзакции то, чего не было в начале). Он имеет больше накладных расходов, чем только для чтения.

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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