Как работает кэш второго уровня Hibernate? Часть 2

В первой части мы рассмотрели концепцию кэша второго уровня и способы его конфигурации. Во второй части рассмотрим стратегии кэширования и конфигурацию EhCache.

Пример проекта в котором Вы можете посмотреть работу кэша и поэксперементировать находится на GitHub.

Подробнее

Как работает кэш первого уровня в Hibernate? Примеры

Введение

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

Кэш первого уровня в Hibernate включен по умолчанию и Вам не нужно ничего предпринимать, чтобы включить его. Даже выключить его не удастся. На самом деле, в роли кэша в сессии выступает Persistence Context. В приложении Hibernate, мы говорим что одна сессия имеет один внутренний persistence context. В JPA приложении, EntityManager имеет так же свой persistence context.

Подробнее

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

Введение

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

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

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

Подробнее

Как логировать Hibernate? Используем правильную конфигурацию

Введение

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

Поэтому я предпочитаю использовать две разных конфигурации:

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

Подробнее

13 способов улучшить производительность JPA и Hibernate

Введение

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

Итак, поехали!

Подробнее

Как настроить механизм dirty checking в Hibernate?

Введение

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

Кастомные стратегии dirty checking

Hibernate предлагает следующие механизмы кастомизации:

Подробнее

Что такое dirty checking механизм Hibernate?

Введение

Persistence контекст ставит в очередь переходы между состояниями сущностей, которые транслируются в SQL выражения на этапе сброса (flush). Для управляемых сущностей, Hibernate автоматически обнаруживает входящие изменения и планирует операции SQL UPDATE за нас. Этот механизм называется автоматической «грязной» (dirty) проверкой.

Подробнее

Как не потерять данные при работе веб приложения?

Введение

В этой статье я расскажу как не потерять данные при работе веб-приложения.

Все запросы БД выполняются в контексте физической транзакции, даже если мы не делаем явного объявления границ транзакций (BEGIN/COMMIT/ROLLBACK). Целостность данных обеспечивается свойствами ACID транзакций БД.

Подробнее

Руководство для начинающих: ACID и транзакции БД

Введение

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

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

transaction-workflow1

По сути транзакции характеризуются следующими четырьмя свойствами (также известными как ACID):

  1. Атомарность
  2. Консистентность
  3. Изоляция
  4. Долговечность

В реляционной БД каждое SQL выражение должно исполняться в пределах транзакции. Без явного определения границ транзакции БД будет использовать неявную транзакцию, которая покрывает  каждое SQL выражение. Неявная транзакция начинается до того как выражение запустится и заканчивается (коммит или откат) после того как выражение выполнится.

Режим неявной транзакции известен так же как режим autocommit.

Для enterprise систем режим автокоммита следует избегать из-за серьезных проблем с производительностью, и данный режим не позволит включать группу множественных DML в единую атомарную «единицу работы».

Это очень важно понимать и далее мы обсудим каждое из свойств.

Подробнее

Как работает flush в Hibernate?

Введение

В этой статье мы поговорим об операции flush. Операция flush позволяет нам сихронизировать in-memory состояние Persistence контекста с БД (т.е. записывает изменения в БД). Но сначала обсудим состояния сущности.

Согласно документации Hibernate сущность может быть в одном из следующих состояний:

  • new/transient:  состояние, в котором, новый созданный объект, о чьем существовании не знает СУБД и он не привязан к persistance контексту.
  • persistent: сущность привязана к persistence контексту (находясь в кэше первого уровня) и есть запись в БД отбражающая эту сущность.
  • detached: сущность была привязана к persistence контексту, но контекст закрылся, а сущность осталась.
  • removed: сущность в данном состоянии помечена как удаленная и persistence контекст удалит ее из БД, когда наступит flush-time.

Передвижение объекта из одного состояния в другое выполняется вызовом методов EntityManager:

  • persist()
  • merge()
  • remove()

Каскадное выполнение позволяет распространять изменение от родительского объекта к дочернему, также облегчая управление отношениями между объектами.

В течение flush time, Hibernate транслирует изменения записанные текущим Persistence контекстом в SQL запросы.

Когда происходит flush?

Flush происходит в трех ситуациях:

  • Когды вы делает commit транзакции Hibernate
  • До того как выполняется запрос в БД
  • Когда вы вызываете entityManager.flush()

Особенно важно понять вторую из этих ситуаций — entityManager делает flush до выполнения запроса. Это происходит не для каждого запроса! Важно учесть, что цель сессии Hibernate минимизировать количество операций записи в БД, поэтому она не делает flush, когда не считает это необходимым.

Подробнее