Что такое ленивая загрузка в Hibernate?
Что такое ленивая загрузка в Java? Я не понимаю процесс. Кто-нибудь может помочь мне понять процесс отложенной загрузки?
Скажем, у вас есть родитель, и у этого родителя есть коллекция детей. Hibernate теперь может «лениво загружать» дочерние элементы, что означает, что он фактически не загружает все дочерние элементы при загрузке родительского элемента. Вместо этого он загружает их по запросу. Вы можете запросить это явно или, что гораздо чаще, hibernate будет загружать их автоматически при попытке доступа к дочернему элементу.
Lazy-loading может помочь значительно улучшить производительность, так как часто дети вам не нужны и поэтому они не будут загружаться.
Также остерегайтесь проблемы n + 1. Hibernate не будет загружать все дочерние элементы при доступе к коллекции. Вместо этого он загрузит каждого ребенка в отдельности. При выполнении итерации по коллекции это вызывает запрос для каждого дочернего элемента. Чтобы избежать этого, вы можете обмануть hibernate для загрузки всех дочерних элементов одновременно, например, вызвав parent.getChildren (). Size ().
Это экономит затраты на предварительную загрузку / предварительное заполнение всех сущностей в большом наборе данных заранее, в то время как вам, в конце концов, не нужны все из них.
Объект, который не содержит всех необходимых вам данных, но знает, как их получить.
Таким образом, при загрузке данного объекта идея состоит в том, чтобы не пытаться загружать связанные объекты, которые вы не можете использовать немедленно, чтобы сэкономить связанные с этим затраты производительности. Вместо этого связанный объект (ы) будет загружен только при использовании.
Это не шаблон, специфичный для доступа к данным и Hibernate, но он особенно полезен в таких областях, и Hibernate поддерживает ленивую загрузку ассоциаций «один ко многим» и ассоциаций «один к одному» и «многие к одному». при определенных условиях. Ленивое взаимодействие обсуждается более подробно в Главе 19 Справочной документации по Hibernate 3.0.
Ленивое извлечение решает, загружать ли дочерние объекты при загрузке родительского объекта. Вы должны сделать эту настройку соответствующего файла отображения hibernate родительского класса. Lazy = true (означает не загружать дочерние элементы). По умолчанию отложенная загрузка дочерних объектов имеет значение true.
Это гарантирует, что дочерние объекты не загружаются, если они явно не вызваны в приложении путем вызова getChild() метода для parent. В этом случае hibernate выдает новый вызов базы данных, чтобы загрузить дочерний getChild() объект, когда он фактически вызывается для родительского объекта.
Но в некоторых случаях вам нужно загрузить дочерние объекты, когда родительский загружен. Просто сделайте lazy = false, и hibernate загрузит дочерний элемент при загрузке parent из базы данных.
Пример: если у вас есть СТОЛ? EMPLOYEE отображается на объект Employee и содержит набор объектов Address. Родительский класс: класс сотрудников, дочерний класс: адресный класс
Hibernate Proxy — для чего используются и как получить исходный объект
Hibernate использует прокси-объекты для реализации ленивой загрузки (lazy load) связей «к-одному». Их также можно использовать для улучшения производительности некоторых операций записи.
Упоминания прокси-объектов вы могли встречать при отладке или в логах. Имя класса прокси состоит из имени класса сущности и суффикса, который зависит от версии Hibernate и библиотеки для работы с байт-кодом, которую использует Hibernate.
В этой статье рассмотрим, как определить, является ли объект прокси, поговорим о распространенной проблеме при работе с ними, и о том, как инициализировать его поля и получить оригинальный объект (unproxy).
Как Hibernate генерирует прокси
Hibernate генерирует класс для прокси как подкласс вашей сущности. Начиная с Hibernate 5.3 для его генерации используется Byte Buddy. В более старых версиях использовался Javassist и CGLIB.
Сгенерированный прокси перехватывает все вызовы методов и проверяет, был ли инициализирован проксируемый объект. При необходимости перед выполнением перехваченного метода выполняется запрос к базе данных для инициализации сущности. Если это происходит без активной Hibernate Session, то бросается исключение LazyInitializationException.
Как получить прокси-объект
Прежде чем я покажу вам, как инициализировать и депроксировать прокси-объект давайте посмотрим на два наиболее распространенных случая, когда вы встретите прокси.
Проксированные lazy-ассоциации «к-одному»
Используя ленивую загрузку для ассоциаций «к-одному» вы создаете проблему вашему persistence-провайдеру. Теперь он должен придумать, как узнать, что ваш код хочет использовать ассоциацию и получить связанный объект из базы данных. Для ассоциаций «ко-многим» Hibernate решает эту проблему, инициализируя атрибут собственными реализациями коллекций. Но это не работает для ассоциаций «к-одному». Hibernate не требует от ваших сущностей реализации каких-либо интерфейсов, которые потом он мог бы имплементировать. Тогда остается два варианта:
Добавить некоторый код в get-метод
Сгенерировать прокси-класс, являющийся подклассом вашей сущности.
Первый вариант требует изменения байткода. Это тема для другой статьи, подробнее об этом я расскажу в онлайн-тренинге Hibernate Performance Tuning. В этой статье мы сконцентрируемся на генерации прокси.
Получение прокси для инициализации ассоциации
Можно получить прокси для сущности, вызвав метод getReference у EntityManager или Hibernate Session. В результате возвращается объект, который можно использовать для ассоциации «к-одному» при создании или изменении сущности.
Как вы можете видеть из нижеприведенного лога Hibernate, вызов метода getReference не инициирует запрос к базе данных. Hibernate создает экземпляр прокси-объекта и устанавливает значение только для первичного ключа. Выполнение запроса откладывается до вызова геттера или сеттера для любого поля, не являющегося первичным ключом.
Как определить прокси-объект
Часто LazyInitializationException дает вам понять, что вы работаете с прокси. Hibernate бросает это исключение, если вы обращаетесь к геттеру или к любому полю, кроме первичного ключа, неинициализированного прокси-объекта.
Как инициализировать прокси
Самый простой и наиболее часто используемый подход для инициализации прокси-объекта заключается в вызове геттера или сеттера атрибута, не являющегося первичным ключом. Hibernate проверяет, инициализирован ли прокси, и если нет, то выполняет SQL-запрос, который извлекает сущность перед вызовом вашего геттера или сеттера.
Как получить исходную сущность из прокси
Проблема при работе с прокси
Как я объяснял ранее, Hibernate генерирует прокси-объект, который является подклассом вашего класса сущности. Это может стать проблемой, если ваша ассоциация «к-одному» ссылается на суперкласс в иерархии наследования. В этом случае Hibernate генерирует другой подкласс этого суперкласса, и вы не сможете легко привести его к своему подклассу.
Резюме
Hibernate использует сгенерированные прокси-классы для поддержки ленивой загрузки ассоциаций «к-одному», и вы можете использовать их для инициализации ассоциаций к другим сущностям. Как только вы вызываете геттер или сеттер для поля, не являющегося первичным ключом, Hibernate выполняет SQL-запрос для получения связанной сущности.
Если вы хотите инициализировать прокси-объект, вам нужно делать это с активной сессией Hibernate Session. В противном случае Hibernate выбросит исключение LazyInitializationException.
Если у вас есть lazy-ассоциация «к-одному» к суперклассу в иерархии наследования, то вы не сможете привести прокси-объект в какому-либо из ваших подклассов. Сначала вам нужно получить оригинальную сущность через unproxy.
Всех желающих приглашаем на открытый урок «Telegram bot для получения курса валют». На занятии создадим пользовательский интерфейс, для этого мы сделаем Telegram bot-а. Через него конечный пользователь сможет получать курс валют.
>> РЕГИСТРАЦИЯ
Hibernate: ленивая загрузка, наследование и instanceof
Рассмотрим, в качестве примера, следующую ситуацию. У нас имеется класс User с полями, описывающими пользователя. Имеется класс Phone, который является родительским для классов CellPhone и SatellitePhone. В классе User есть поле содержащее список телефонов пользователя. В целях уменьшения нагрузки на БД мы сделали этот список «ленивым». Он будет загружаться только по требованию.
В такой конфигурации при запросе списка телефонов конкретного пользователя мы можем получить как список проинициализированных объектов-телефонов (например, если они уже есть в кэше), так и список proxy-объектов.
В большинстве ситуаций нам не важно с чем именно мы работаем (реальным объектом или его proxy). При запросе какого-либо поля какого-либо объекта — proxy-объект автоматически проинициализируется, и мы получим ожидаемые данные. Но если нам нужно узнать тип объекта, то все идет наперекосяк.
Давайте разберемся почему так происходит. Основная проблема заключается в том, что Hibernate — не экстрасенс и не может знать заранее (не выполнив запросы к БД) какого типа объекты содержатся в списке. В соответствии с этим создает список, содержащий proxy-объекты, унаследованные от Phone.
Когда наша команда в первый раз столкнулась с данной проблемой мы немного изучили данный вопрос и поняли, что придется делать «костыль». Ошибка возникала в сервисном методе где нужно было точно знать с каким из дочерних классов мы имеем дело. Мы прямо перед этой проверкой внедрили другую: если объект является proxy-объектом, то он инициализируется. После чего благополучно забыли эту неприятную историю.
Со временем проект все рос, бизнес-логика усложнялась. И вот настал момент, когда подобных костылей стало уже слишком много (мы поняли, что так дело не пойдет на третьем или четвертом костыле). Причем данная проблема стала возникать не только при запросе у одного объекта ленивого списка других объектов, но и при прямом запросе из базы данных списка объектов. Отказываться от ленивой загрузки очень не хотелось т.к. база у нас и так сильно нагружена. Мы решили больше не перемешивать архитектурные слои приложения и создать что-нибудь более универсальное.
Схема нашего приложения
В данной схеме запросами к БД занимается DAO слой. Он состоит из 1 абстрактного класса JpaDao в котором определены все базовые методы по работе с базой данных. И множества классов — его наследников, каждый из которых в конечном итоге использует методы базового класса. Итак, как мы побороли проблему с прямым запросом списка объектов разных типов с общим родителем? Мы создали в классе JpaDao методы для инициализации одного прокси-объекта и инициализации списка прокси-объектов. При каждом запросе списка объектов из БД этот список проходит инициализацию (Мы сознательно пошли на такой шаг т.к. если мы запрашиваем какой-то список объектов в нашем приложении — то почти всегда он нужен полностью проинициализированным).
С решением первой проблемы все получилось не так гладко. Вышеописанный способ не подходит так как ленивой загрузкой занимается непосредственно Hibernate. И мы пошли на небольшую уступку. Во всех объектах, содержащих ленивые списки разных типов объектов с одним родителем (например, User со списком Phone) мы переопределили геттеры для этих списков. Пока списки не запрашиваются — все в порядке. Объект содержит только прокси-список и не выполняются лишние запросы. При запросе списка происходит его инициализация.
Нетерпеливая/Ленивая Загрузка В Спящем Режиме
Быстрое и практическое знакомство с различными подходами к загрузке данных – ленивыми и нетерпеливыми – в режиме гибернации.
1. введение
При работе с ORM извлечение/загрузка данных может быть разделена на два типа: нетерпеливая и ленивая.
В этой краткой статье мы укажем на различия и покажем, что их можно использовать в режиме гибернации.
2. Зависимости Maven
Чтобы использовать Hibernate, давайте сначала определим основную зависимость в вашем pom.xml :
3. Нетерпеливая и ленивая загрузка
Первое, что мы должны обсудить здесь, – это то, что такое ленивая загрузка и нетерпеливая загрузка:
Давайте посмотрим, как это на самом деле работает, на некоторых примерах:
Пользователь Ленивый Класс :
В следующем разделе мы увидим, как приведенный выше пример реализован в режиме гибернации.
4. Конфигурация Загрузки
В этом разделе мы рассмотрим, как мы можем настроить стратегии выборки в режиме гибернации. Мы будем повторно использовать примеры из предыдущего раздела.
Отложенную загрузку можно просто включить, используя следующий параметр аннотации:
Для использования нетерпеливой выборки используется следующий параметр:
В следующем разделе мы рассмотрим различия между двумя типами выборки.
5. Различия
Как мы уже упоминали, основное различие между двумя типами выборки заключается в моменте, когда данные загружаются в память.
Давайте взглянем на этот пример:
При использовании подхода ленивой инициализации Набор OrderDetail будет инициализирован только в том случае, если он явно вызывается с помощью геттера или какого-либо другого метода, как показано в приведенном выше примере:
Но при активном подходе в Пользователь стремится он будет инициализирован немедленно в первой строке приведенного выше примера:
Идея отключения прокси-серверов или ленивой загрузки считается плохой практикой в режиме гибернации. Это может привести к тому, что большое количество данных будет извлечено из базы данных и сохранено в памяти, независимо от необходимости в этом.
Для проверки вышеуказанной функциональности можно использовать следующий метод:
Теперь важно взглянуть на запросы, которые генерируются в любом случае:
Приведенная выше настройка в fetching.hbm.xml показывает сгенерированные SQL-запросы. Если вы посмотрите на вывод консоли, то сможете увидеть сгенерированные запросы.
Для ленивой загрузки запроса, который создается для загрузки Пользовательских данных:
Однако при быстрой загрузке мы увидели, что соединение выполняется с помощью USER_ORDER:
6. Преимущества и недостатки
6.1. Ленивая загрузка
6.2. Нетерпеливая Загрузка:
7. Ленивая загрузка в спящем режиме
Hibernate применяет подход с отложенной загрузкой к сущностям и ассоциациям, предоставляя прокси-реализацию классов.
Следует также отметить, что когда ассоциация представлена как класс коллекции (в приведенных выше примерах она представлена как Set orderDetailSet ), то создается оболочка и заменяется исходной коллекцией.
8. Заключение
В этой статье мы показали примеры двух основных типов выборки, используемых в режиме гибернации.
Hibernate: использование lazy initialization в разработке клиент-серверного приложения
При проектировании доменов приложения, разрабатываемого с использованием Hibernate, разработчику необходимо сделать выбор: инициализировать ли свойства домена, соответствующие коллекциям связанных доменов, сразу (FetchType=EAGER) или же делать это только при обращении к ним (FetchType=LAZY). На самом деле в случае, когда предметная область имеет сколь-либо сложную структуру связей между объектами, выбор уже сделан – загружать полбазы ради одного объекта, как это было бы при FetchType=EAGER, мягко говоря, неразумно. Поэтому ленивая инициализация в случае коллекций есть наиболее предпочтительная стратегия инициализации связанных объектов.
Однако, не всё так просто. Ленивая инициализация реализуется за счёт создания прокси-объекта с помощью JDK Dynamic Proxy или библиотеки CGLIB. В обоих случаях проксирование соответствующих get-методов сводится к обращению к сессии Hibernate для получения необходимых данных. Последнее же в свою очередь означает, что обращение к ленивым свойствам объекта может быть осуществлено только при наличии сессии Hibernate. В противном случае, попытка получить свойство объекта приведёт к незабвенному исключению «LazyInitializationException: could not initialize proxy — the owning Session was closed».
Понятно, что иметь открытую сессию под рукой можно далеко не всегда, что доставляет некоторые неудобства. Так, например, для того, что бы использовать домены с ленивой инициализацией в шаблонах MVC-приложения придётся прибегнуть к методике «OpenSessionInView», суть которой сводится к созданию фильтра, обеспечивающего открытие сессии в начале обработки запроса и её закрытие в конце.
Но, что делать, если домены с загруженными данными нужно использовать вне сессии Hibernate? Например, в случае клиент-серверной архитектуры, когда серверу необходимо передать домены клиенту? Разумеется, что об открытие сессии на стороне клиента не может идти и речи, хотя бы потому, что в общем случае о БД ему ничего не известно. Единственным выходом из ситуации, на мой взгляд, будет «депроксирование» объектов доменов и инициализация их необходимыми данными перед передачей от сервера клиенту.
При таком раскладе слой бизнес логики может спокойно работать с прокси-объектами доменов в рамках сессии Hibernate. Роль слоя служб при этом сводится получению необходимых данных от слоя бизнес-логики и компоновки данных для клиента: создание DTO-объектов на базе классов доменов с помощью копирования определённой глубины и детализации.
Вопрос остаётся только в том, как провести это «депроксирование». В принципе это можно сделать с помощью самого Hibernate’a:
public static T initializeAndUnproxy(T entity) <
if (entity == null ) <
throw new
NullPointerException( «Entity passed for initialization is null» );
>
Такой подход инициализирует все коллекции заданного объекта и «достанет» его из прокси. Однако, у него есть целый ряд недостатков: инициализируются все коллекции подряд и депроксируется только родительский объект (как минимум потому, что непонятно, на сколько глубоко нужно спуститься по графу связей объекта при депроксировании).
Решением в данной ситуации может послужить создание небольшого класса-утилиты, который будет выполнять депроксирование домена путём создания нового объекта того же класса и инициализации свойств, соответствующих базовым классам Hibernate’a. Все остальные свойства объекта будут инициализироваться слоем служб по мере необходимости.
Я не берусь, утверждать, что данный подход является оптимальным и/или единственно верным. Если у вас есть предложения, как решить проблему иначе, — буду рад их услышать.
