В первой части мы рассмотрели концепцию кэша второго уровня и способы его конфигурации. Во второй части рассмотрим стратегии кэширования и конфигурацию EhCache.
Пример проекта в котором Вы можете посмотреть работу кэша и поэксперементировать находится на GitHub.
Кэширование это возможность предоставляемая ORM фреймворками, которая помогает пользователям достичь высокую скорость, и в то же время помогает самим фреймворкам уменьшить количество обращений к БД. Hibernate достигает вторую цель вводя кэш первого уровня.
Кэш первого уровня в Hibernate включен по умолчанию и Вам не нужно ничего предпринимать, чтобы включить его. Даже выключить его не удастся. На самом деле, в роли кэша в сессии выступает Persistence Context. В приложении Hibernate, мы говорим что одна сессия имеет один внутренний persistence context. В JPA приложении, EntityManager имеет так же свой persistence context.
При разработке приложений, связанных с ORM, я уже сталкивался с ситуациями, когда производительность приложения падала по причине большого траффика к БД. Hibernate единственный ORM фреймворк, которые помогает преодолеть такие сложные ситуации с помощью кэширования. В этой статье я попытаюсь дать детальное описание этой функции.
В веб-приложениях , используя Hibernate, кэш на самом деле хранит данные уже загруженные из БД. Это помогает уменьшить трафик между нашим приложением и БД. Большинство случаев извлечения данных попадает на кэш. Всякий раз когда нужны новые данные, будет сделан запрос в БД. Поскольку время, необходимое для доступа к БД, больше по сравнению с временем доступа к кэшу, трафик будет уменьшен между приложением и БД. В кэше хранятся только данные, связанные с текущим запущенным приложением. Следовательно, кэш должен быть очищен всякий раз когда приложение изменяется. Давайте рассмотрим как это все делается ниже.
Для поиска источника проблем с производительностью нашего приложения мы подбираем нужную конфигурацию логирования. Выбор конфигурации также влияет на создаваемую лишнюю нагрузку, которая замедляет работу приложения. Вы должны решить, какую именно информацию нужно извлекать в лог.
Поэтому я предпочитаю использовать две разных конфигурации:
Hibernate является самой популярной имплементацией JPA. Эта популярность принесла несколько преимуществ всем пользователям. Уже написано множество статей в блогах, вопросов и ответов на популярных форумах и успешных советов по улучшению работы Hibernate. В этой статье я хочу суммировать некоторые лучшие практики для JPA и Hibernate, которые помогут Вам избежать распространненых ошибок и создать лучшее приложение.
Итак, поехали!
В моей предыдущей статье я описал механизм автоматической dirty проверки в Hibernate. Хотя мало кто и задумывается о том как это все работает и используют стратегию по дефолту, может много раз возникнуть ситуация, когда требуется добавить свою собственную стратегию обнаружения изменений в сущностях.
Hibernate предлагает следующие механизмы кастомизации:
Persistence контекст ставит в очередь переходы между состояниями сущностей, которые транслируются в SQL выражения на этапе сброса (flush). Для управляемых сущностей, Hibernate автоматически обнаруживает входящие изменения и планирует операции SQL UPDATE за нас. Этот механизм называется автоматической «грязной» (dirty) проверкой.
В этой статье я расскажу как не потерять данные при работе веб-приложения.
Все запросы БД выполняются в контексте физической транзакции, даже если мы не делаем явного объявления границ транзакций (BEGIN/COMMIT/ROLLBACK). Целостность данных обеспечивается свойствами ACID транзакций БД.
В этой статье мы поговорим об операции flush. Операция flush позволяет нам сихронизировать in-memory состояние Persistence контекста с БД (т.е. записывает изменения в БД). Но сначала обсудим состояния сущности.
Согласно документации Hibernate сущность может быть в одном из следующих состояний:
Передвижение объекта из одного состояния в другое выполняется вызовом методов EntityManager:
Каскадное выполнение позволяет распространять изменение от родительского объекта к дочернему, также облегчая управление отношениями между объектами.
В течение flush time, Hibernate транслирует изменения записанные текущим Persistence контекстом в SQL запросы.
Flush происходит в трех ситуациях:
entityManager.flush()Особенно важно понять вторую из этих ситуаций — entityManager делает flush до выполнения запроса. Это происходит не для каждого запроса! Важно учесть, что цель сессии Hibernate минимизировать количество операций записи в БД, поэтому она не делает flush, когда не считает это необходимым.
Все проекты с которыми я работал использовали пул соединений к БД и для этого есть веские причины. Иногда мы можем забыть зачем применили какой-то шаблон проектирования или технологию, поэтому стоит сделать шаг назад и объяснить это. Каждое технологическое решение имеет и достоинства и недостатки, и если вы не видите каких-то недостатков, то нужно задуматься что вы пропустили.
Каждая операция чтения или записи из БД требует соединения. Так давайте же представим как выглядит цикл соединения с БД:
Этапы: