Как работает кэш в Hibernate?

Введение

При разработке приложений, связанных с ORM, я уже сталкивался с ситуациями, когда производительность приложения падала по причине большого траффика к БД. Hibernate единственный ORM фреймворк, которые помогает преодолеть такие сложные ситуации с помощью кэширования. В этой статье я попытаюсь дать детальное описание этой функции.

Как работает кэш Hibernate?

В веб-приложениях , используя Hibernate, кэш на самом деле хранит данные уже загруженные из БД. Это помогает уменьшить трафик между нашим приложением и БД. Большинство случаев извлечения данных попадает на кэш. Всякий раз когда нужны новые данные, будет сделан запрос в БД. Поскольку время, необходимое для доступа к БД, больше по сравнению с временем доступа к кэшу, трафик будет уменьшен между приложением и БД. В кэше хранятся только данные, связанные с текущим запущенным приложением. Следовательно, кэш должен быть очищен всякий раз когда приложение изменяется. Давайте рассмотрим как это все делается ниже.

Hibernate использует следующие кэши для объектов:

hibernatecaching02

  • First-level cache (Кэш первого уровня): Он всегда связан с объектом Session. Это обязательный кэш, через который проходят все запросы. Hibernate использует этот кэш по умолчанию. Если у Вас возникла необходимость много раз обновлять объект, Hibernate пытается задержать выполенение этих обновлений насколько это возможно для уменьшения количества вызовов SQL UPDATE. Он завершает эту транзакцию только в конце транзакции.
  • Second-level cache (Кэш второго уровня): Он всегда связан с объектом Session Factory. Это опциональный кэш. Кэш второго уровня создается на уровне session factory и доступен для использования во всех сессиях, которые создаются используя конкретную данную фабрику сессий. Кэш вторго уровня может быть сконфигурирован отдельно для каждого класса и коллекции и в основном отвечает за кэширование между сеансами. Это означает, что в момент когда session factory закроется, весь кэш связанный с ним очиститься и cache менеджер также закроется.
  • Query Cache (Кэш запросов): Кэш запросов используется для кэширования результатов запроса. Когда кэш запроса включен, результаты запроса сохраняются  вместе с комбинацией запросов и параметров вызова. Каждый раз запрос вызовет проверку на наличие результата у кэш менеджера. Если результаты найдены в кэше, они возвращаются, иначе инициализируется транзакция в БД.
  • Любой сторонний кэш может быть использован в Hibernate. Предоставляется интерфейс org.hibernate.cache.CacheProvider, который должен быть имплементирован для использования стороннего провайдера кэша.

Стратегии конкурентности

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

Read-only (Только чтение)

  • Полезно для данных, которые часто читаются, но никогда не обновляются.
  • Простая в использовании
  • Лучшая производительность среди всех
  • Безопасно для использования в кластере.

Пример для использования стратегии read-only.

<hibernate-mapping>
<class name="Student" table="STUDENT">
<meta attribute="class-description"> 
This class contains the STUDENT detail. 
</meta>
<cache usage="read-only"/>
....
</class>
..........
</hibernate-mapping>

Использование атрибута «read-only» сообщает Hibernate что нужно использовать стратегию read-only для заданного кэша.

Read-Write (Запись-чтение)

  • Используется в случае, когда наши данные необходимо обновлять.
  • Есть больше оверхеда чем при применении стратегии read-only
  • Не используется если требуется уровнь изоляции Serializable
  • В среде JTA, для получения JTA Transaction Manager мы должны заполнить свойство hibernate.transaction.manager_lookup_class
  • Для использования в кластере имплементация кэша должна поддерживать блокировку.

Пример для использования данной стратегии:


<hibernate-mapping>
<class name="Student" table="STUDENT">
<meta attribute="class-description"> 
This class contains the STUDENT detail. 
</meta>
<cache usage="read-write"/>
....
</class>
..........
</hibernate-mapping>

Nonstrict read-write (Нестрогое чтение-запись)

  • Необходимо использовать, если приложение редко обновляет данные
  • Мы должны заполнить hibernate.transaction.manager_lookup_class для использования в JTA
  • Транзакция завершается, когда вызывается Session.close() или Session.disconnect() в других средах (кроме JTA)

Пример:


<class name="abc.xyz" .... >

<cache usage=" nonstrict-read-write"/>

….

</class>

Transactional

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

Имплементации кэша

Теперь мы поняли как выбрать стратегии, и надо выбрать провайдера кэша. Hibernate принуждает Вас выбрать единственного провайдера кэша на все приложение. Каждый провайдер кэша не совметсим с каждой стратегией. Hibernate подерживает следующие опенсорсные имлементации кэша: EHCache (Easy Hibernate Cache), OSCache (Open Symphony Cache), Swarm Cache, JBoss Tree Cache.

Давайте рассмотрим каждого:

EHCache (Easy Hibernate Cache)

  • Быстрый, легковесный и легкий в использовании
  • Поддерживает только стратегии read-only и read-write
  • Поддерживает кэширование на диске и в памяти
  • Не поддерживает кластеризацию

OSCache (Open Symphony Cache) (org.hibernate.cache.OSCacheProvider)

  • Мощный и гибкий
  • Поддерживает только стратегии read-only и read-write
  • Поддерживает кэширование на диске и в памяти
  • Обеспечивает базовую поддержку для кластеризации через JavaGroups или JMS

SwarmCache (org.hibernate.cache.SwarmCacheProvider)

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

TreeCache (org.hibernate.cache.TreeCacheProvider) из JBoss

  • мощный, реплицируемый (синхронно или асинхронно) и транзакционный кэш
  • полезный, когда нам нужно правильная транзакционная архитектура кэша

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

Cache Provider Read-Only Nonstrict Read-Only Read-Write Transactional
EHCache Yes Yes Yes
OSCache Yes Yes Yes
SwarmCache Yes Yes
TreeCache Yes Yes

Вывод

В этой статье мы рассмотрели что такое кэширование Hibernate, типы конкурентных стратегий. Мы также рассмотрели доступных провайдеров кэша и как их выбрать. Спасибо за внимание!

(Visited 917 times, 1 visits today)

Добавить комментарий

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.