Состояния entity в Hibernate

var a1 = s.find(Author.class, 1L);
var a2 = s.find(Author.class, 1L);
var a3 = s.find(Author.class, 1L);
// это один и тот же объект: true
// запросов к базе: 1

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 15, остальные разбираются в тренажёре.

1. #entity_lifecycle1 / 5
   Что такое контекст персистентности (persistence context) и кэш первого уровня?

   A)Глобальный кэш, разделяемый всеми сессиями и потоками приложения на всё время его работы

   B)Область в рамках сессии, где хранятся managed-сущности; гарантирует их идентичность

   C)Файл на диске, куда Hibernate сбрасывает все загруженные сущности между перезапусками приложения

   D)Пул соединений с базой данных, из которого сессии берут подключение для выполнения запросов

   показать ответ и разбор

   +B)Область в рамках сессии, где хранятся managed-сущности; гарантирует их идентичность

   // разбор: Контекст персистентности (у Hibernate — Session, в JPA — EntityManager) хранит все managed-сущности в пределах одной единицы работы. Это и есть кэш ПЕРВОГО уровня (L1): он ВСЕГДА включён и локален для сессии. Следствия: повторный find по тому же id вернёт ТОТ ЖЕ экземпляр (гарантия идентичности, repeatable read внутри сессии) без второго SELECT; изменения managed-сущностей отслеживаются (dirty checking) и сбрасываются при flush. При закрытии сессии контекст очищается, а сущности становятся detached. L1 нельзя отключить.

2. #entity_lifecycle2 / 5
   Как Hibernate узнаёт, что managed-сущность изменилась, без явного вызова save?

   A)Он не узнаёт: чтобы сохранить изменения managed-сущности, нужно явно вызвать save/update

   B)Он перехватывает каждое присваивание поля через рефлексию и сразу шлёт UPDATE в базу немедленно

   C)Через dirty checking: сравнивает состояние с снимком и генерирует UPDATE при flush

   D)Он требует, чтобы каждое изменяемое поле было помечено аннотацией @Dirty для отслеживания вручную

   показать ответ и разбор

   +C)Через dirty checking: сравнивает состояние с снимком и генерирует UPDATE при flush

   // разбор: Пока сущность MANAGED, Hibernate хранит снимок её исходного состояния. При flush (перед запросом/коммитом) он сравнивает текущее состояние со снимком (dirty checking) и генерирует UPDATE ТОЛЬКО для реально изменившихся сущностей/полей — явный save вызывать не нужно (это удивляет новичков: «я не сохранял, а в БД изменилось»). Обратная сторона: случайное изменение managed-сущности молча уйдёт в БД. Поэтому важны границы транзакции, readOnly для запросов (отключает dirty checking) и работа с DTO там, где менять не нужно.

3. #entity_lifecycle3 / 5
   Чем persist отличается от merge?

   A)Persist и merge делают одно и то же; merge оставлен лишь для совместимости со старым кодом JPA

   B)Persist сохраняет только в кэш, а merge — только в базу; для полного сохранения нужны оба вызова

   C)Merge удаляет сущность из контекста, а persist добавляет — это операции с противоположным смыслом

   D)persist — для новой (transient) сущности; merge — вернуть detached в контекст (копией)

   показать ответ и разбор

   +D)persist — для новой (transient) сущности; merge — вернуть detached в контекст (копией)

   // разбор: persist рассчитан на TRANSIENT-сущность (новую): делает её managed, при flush — INSERT. merge работает с DETACHED-сущностью (например, пришедшей из прошлой сессии/по сети): он НЕ делает переданный объект managed, а КОПИРУЕТ его состояние в managed-экземпляр (загрузив его при нужде) и ВОЗВРАЩАЕТ этот управляемый объект — работать дальше надо с возвращённым, а не с исходным. Частая ошибка — вызвать merge и продолжить менять исходную detached-сущность, ожидая сохранения. persist к detached бросит исключение.

4. #entity_lifecycle4 / 5
   Что делает flush() и отличается ли он от commit транзакции?

   A)flush синхронизирует контекст с БД (шлёт SQL), но НЕ коммитит транзакцию

   B)Flush и commit — синонимы: оба немедленно и окончательно фиксируют изменения в базе данных без отката

   C)Flush очищает кэш первого уровня, удаляя из контекста все загруженные ранее сущности сессии

   D)Flush откатывает все несохранённые изменения сущностей, возвращая их к состоянию на начало транзакции

   показать ответ и разбор

   +A)flush синхронизирует контекст с БД (шлёт SQL), но НЕ коммитит транзакцию

   // разбор: flush() СИНХРОНИЗИРУЕТ контекст персистентности с БД: отправляет накопленные SQL-команды (INSERT/UPDATE/DELETE от dirty checking) на сервер — но в рамках ТЕКУЩЕЙ транзакции, которая ещё НЕ закоммичена (изменения можно откатить). commit фиксирует транзакцию окончательно (и обычно сам вызывает flush перед этим). Hibernate флашит автоматически: перед выполнением запроса (чтобы он видел свежие данные) и перед commit. Понимание flush объясняет, почему исключения БД (constraint) могут вылететь в неожиданный момент — на flush, а не на строке setField.

5. #entity_lifecycle5 / 5
   В каком состоянии окажется сущность после закрытия сессии/транзакции?

   A)Removed — закрытие сессии автоматически удаляет из базы все загруженные в ней сущности

   B)Detached — она больше не отслеживается контекстом

   C)Transient — сущность теряет свой id и становится как только что созданная через new

   D)Persistent — сущность продолжает отслеживаться и после закрытия сессии, до конца работы приложения

   показать ответ и разбор

   +B)Detached — она больше не отслеживается контекстом

   // разбор: Когда сессия/EntityManager закрывается (или контекст очищается clear/detach), все managed-сущности переходят в DETACHED: у них сохраняются данные и id, но контекст их больше НЕ отслеживает — изменения полей уже НЕ уходят в БД сами, а обращение к ЛЕНИВЫМ, не загруженным ранее связям бросает LazyInitializationException. Чтобы снова сохранять изменения detached-объекта, его возвращают в контекст через merge. Это ядро частых багов: «поменял объект после транзакции — не сохранилось» и «обратился к lazy-полю в контроллере — упало».