Будьте в спящем режиме стратегия кэша

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

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

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

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.

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