Кэш 2-го уровня Hibernate не кэширует зафиксированные объекты

Мне интересно, возможно ли для кеша второго уровня Hibernate (мы используем EHCache) разрешить приложению кэшировать Entity, который был передан в БД, если он знает, что никакие другие приложения не изменяют БД.

Я считаю, что если я обновляю запись A, то я знаю значение записи A и должен иметь возможность кэшировать это, системы кластеризации JVM, такие как Terracotta, поддерживают этот тип поведения с точки зрения кучи памяти JVM с использованием блокировок синхронизации Java.

Конфигурация режима блокировки EHCache в Hibernate


hibernate caching ehcache second-level-cache
person Dougnukem    schedule 09.09.2009    source источник
comment
Не могли бы вы прояснить, что вы пытаетесь сделать? Вы спрашиваете, как вручную кэшировать объекты после слияния таким образом, чтобы Hibernate использовал их во время последующих вызовов get ()? Может помочь либо образец кода, либо более подробное описание проблемы.   -  person ChssPly76    schedule 15.09.2009

Ответы (1)


arrow_upward
3
arrow_downward

Об этом рассказывает современная книга POJO in Action

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

И...

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

И выберите одну из следующих стратегий в соответствии с JPA с книгой Hibernate

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

Добавлено в исходный anwser: Hibernate НЕ ГАРАНТИРУЕТ согласованность между кешем и базой данных, независимо от того, используете ли вы @Cache (usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE). Если вы хотите его использовать, вам СЛЕДУЕТ настроить достаточно короткий таймаут истечения срока действия, который может повлиять на производительность.

С уважением,

person Arthur Ronald    schedule 12.09.2009
comment
Использование @Cache (usage = CacheConcurrencyStrategy.READ_WRITE) вместо @Cache (usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE) позволило EHCache не аннулировать после обновления объекта. Я не уверен, каковы потери производительности при использовании READ_WRITE по сравнению с NONSTRICT_READ_WRITE. Также мы очень далеко продвинулись в проекте, чтобы полностью включить оптимистичную блокировку с использованием столбца версии и отметок времени, но это также кажется хорошим решением. - person Dougnukem; 15.09.2009
comment
Спасибо, позаботьтесь о проблемах с производительностью при использовании возможностей кеширования. Завтра я расскажу вам об этом подробнее. - person Arthur Ronald; 15.09.2009