Назовите состояния сущности в Hibernate и когда они возникают

Что проверяют

Понимаете ли вы, что персистентный контекст это не просто кэш, а место, где Hibernate сам решает, когда и какой SQL отправить. Состояния спрашивают не ради четырёх заученных слов, а чтобы проверить, объясните ли вы, почему изменение объекта попадает в базу без единого вызова обновления.

Как отвечать

Состояний четыре, и описывать их надо через отношение объекта к персистентному контексту.

transient: объект создан оператором new, контекст о нём не знает, строки в базе нет.

persistent, он же управляемый: объект привязан к открытому контексту. Возникает после persist, после merge, после загрузки через find или запрос. Ключевое свойство это грязная проверка: при сбросе контекста Hibernate сравнивает объект со снимком, сделанным при загрузке, и сам генерирует обновление изменённых полей.

detached: объект был управляемым, но контекст закрыт либо объект из него убран через detach, clear или evict. Правки такого объекта в базу не поедут, вернуть его в контекст можно через merge.

removed: объект помечен к удалению вызовом remove. Строка исчезнет при сбросе контекста, до этого момента объект всё ещё в контексте.

var user = new User();      // transient
em.persist(user);           // persistent
user.setName("Ivan");       // обновление уйдёт само, при flush
em.getTransaction().commit();

Где спотыкаются

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

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

Опираются на устаревший API сессии. Методы сохранения и удаления из старого интерфейса помечены устаревшими в пользу persist и remove, и упоминание их как основных сразу датирует опыт кандидата.