Hibernate Performance Tips: эффект грязной коллекции

Это первый пост из множества других постов:

В прошлом году я посетил Devoxx в качестве докладчика, но также я посетил конференцию Patrycja Wegrzynowicz, посвященную анти- паттернам гибернации . В этой презентации Патрича показывает нам антишаблон, который шокирует меня, потому что он оказался неожиданным.

Мы увидим, какой эффект это имеет, когда Hibernate обнаруживает грязную коллекцию и должен воссоздать ее.

Давайте начнем с модели, которую мы будем использовать, только два класса, связанные с ассоциацией один-ко-многим:

На предыдущих занятиях мы должны обратить внимание на три важных момента:

• мы комментируем на уровне свойств, а не на уровне полей.
• @ OneToMany и @ ManyToOne используют параметры по умолчанию (кроме определения каскада )
• офицер- геттер в классе Starship возвращает неизменный список.

Чтобы протестировать конфигурацию модели, мы собираемся создать тест, который создает и сохраняет один звездный корабль и семь офицеров , а в разных транзакциях и EntityManager находит созданный звездный корабль .

Теперь, когда мы создали этот тест, мы можем запустить его и будем наблюдать за выводом консоли Hibernate .

Посмотрите количество запросов, выполненных во время первого коммита (сохраняющиеся объекты) и во время коммита второй транзакции (поиск звездолета ). Всего и игнорируя генератор последовательностей, мы можем считать 22 вставки , 2 выбора и 1 удаление , что неплохо, когда мы создаем только 8 объектов и 1 находим по первичному ключу.

На этом этапе давайте рассмотрим, почему выполняются эти SQL- запросы:

Первые восемь вставок неизбежны; они требуются путем вставки данных в базу данных.

Следующие семь вставок необходимы, потому что мы аннотировали свойство getOfficers без атрибута mappedBy . Если мы внимательно посмотрим на документацию Hibernate , то мы увидим, что « без описания какого-либо физического сопоставления используется однонаправленное соединение со многими с таблицей соединений ».

Следующая группа запросов еще более странная, первое предложение select — найти Starship по id, но что это за удаления и вставки данных, которые мы уже создали?

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

Поскольку используется таблица соединения, таблицу Starship_Officer следует создать заново, удалив предыдущие вставленные кортежи и вставив новые (хотя они имеют одинаковые значения).

Попробуем исправить эту проблему. Мы начнем с отображения двунаправленной ассоциации «один ко многим», где сторона «многие к одному» является стороной-владельцем.

И теперь мы снова запускаем тот же тест и снова проверяем результат.

Несмотря на то, что мы сократили количество операторов SQL с 25 до 10, у нас все еще есть ненужный запрос, который находится только в секции commit второй транзакции. Почему, если офицеры по умолчанию ленивы (спецификация JPA ), а мы не получаем офицеров в транзакции, Hibernate выполняет выбор из таблицы «Сотрудники»? По той же причине, что и в предыдущей конфигурации, возвращаемая коллекция имеет другой идентификатор Java, поэтому Hibernate помечает его как вновь созданную коллекцию, но теперь очевидно, что операции объединения таблиц больше не требуются. Мы сократили количество запросов, но у нас все еще есть проблемы с производительностью. Вполне вероятно, что нам понадобится какое-то другое решение, и решение не самое очевидное, мы не собираемся возвращать объекты коллекции, возвращенные Hibernate , мы могли бы расширить это позже, но мы собираемся изменить расположение аннотаций.

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

И, наконец, мы снова запустим тест и посмотрим, что произойдет:

Почему при использовании сопоставления свойств Hibernate выполняет запросы во время фиксации, а при использовании сопоставления полей не выполняется? Когда транзакция фиксируется, Hibernate выполняет сброс для синхронизации основного постоянного хранилища с постоянным состоянием, хранящимся в памяти. Когда используется сопоставление свойств, Hibernate вызывает методы getter / setter для синхронизации данных, а в случае метода getOfficers возвращает грязную коллекцию (из-за вызова unmodifiableList ). С другой стороны, когда мы используем сопоставление полей, Hibernate получает непосредственно поле, поэтому сбор не считается грязным и повторное создание не требуется.

Но мы еще не закончили, я полагаю, вам интересно, почему мы не удалили Collections.unmodifiableList из геттера, возвращая коллекцию Hibernate? Да, я согласен с вами, что мы быстро закончили, и изменение выглядело бы как @ OneToMany (cascade = {CascadeType.ALL} ) public List <Officer> getOfficers () {фицеры; } но возвращение исходной коллекции приводит к проблеме инкапсуляции, фактически мы нарушаем инкапсуляцию !. Мы можем добавить в изменяемый список все, что захотим; мы могли бы применить неконтролируемые изменения к внутреннему состоянию объекта.

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

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

Надеюсь, вы нашли этот пост полезным.

Скриншот примера, показанного здесь: