💾 Раздел 16 · Вопрос #21

Какие типы Cascade существуют

Спецификация JPA (Jakarta Persistence) и фреймворк Hibernate предоставляют набор типов каскадирования, определяющих, какие именно операции управления жизненным циклом сущности а...

💾 Hibernate JPA 📄 Исходный Markdown

Спецификация JPA (Jakarta Persistence) и фреймворк Hibernate предоставляют набор типов каскадирования, определяющих, какие именно операции управления жизненным циклом сущности автоматически транслируются от родительского объекта к связанным дочерним сущностям. Понимание специфики каждого типа каскада позволяет выстраивать надежные границы агрегатов по канонам Domain-Driven Design (DDD) и предотвращать случайное удаление разделяемых данных.

🟢 Junior Level

6 стандартных типов CascadeType в JPA

В перечислении jakarta.persistence.CascadeType определены шесть базовых значений:

Тип каскада Какому вызову EntityManager соответствует Поведение при вызове на родителе
PERSIST entityManager.persist(parent) Новые дочерние объекты (Transient) также передаются в persist() и получают статус Managed.
MERGE entityManager.merge(parent) Отсоединенные дочерние объекты (Detached) также объединяются с текущей сессией.
REMOVE entityManager.remove(parent) Дочерние записи удаляются из базы данных при удалении родительской строки.
REFRESH entityManager.refresh(parent) Данные всех дочерних сущностей принудительно перезагружаются из БД.
DETACH entityManager.detach(parent) Все связанные объекты исключаются из кэша L1 и переходят в состояние Detached.
ALL Все операции сразу Активирует все 5 вышеперечисленных стратегий каскадирования одновременно. 
// Пример комбинирования типов каскада:
@Entity
public class Document {
    @Id
    private Long id;

    // Разрешаем сохранять и обновлять вложения вместе с документом,
    // но запрещаем автоматическое удаление:
    @OneToMany(mappedBy = "document", cascade = {CascadeType.PERSIST, CascadeType.MERGE})
    private List<Attachment> attachments = new ArrayList<>();
}

🟡 Middle Level

Нативные типы каскадирования Hibernate (org.hibernate.annotations.CascadeType)

Помимо стандарта JPA, библиотека Hibernate предоставляет собственный расширенный набор аннотаций каскадирования @org.hibernate.annotations.Cascade:

  • SAVE_UPDATE (Legacy Hibernate): Каскадирует вызовы session.saveOrUpdate().
  • LOCK: Каскадно накладывает блокировку session.lock() на связанные сущности.
  • REPLICATE: Каскадно переносит сущности между разными базами данных через session.replicate().

Рекомендация: В современном коде следует всегда использовать стандартный JPA jakarta.persistence.CascadeType, избегая привязки к вендорским аннотациям Hibernate.

Архитектурное правило: Композиция против Ассоциации

Выбор типа каскадирования должен строго следовать модели предметной области (DDD):

                   СТРАТЕГИЯ КАСКАДИРОВАНИЯ ПО ТИПУ СВЯЗИ
                   
  1. КОМПОЗИЦИЯ (Parent владеет Child монопольно)
     Order ──────[1:N]──────> OrderItem
     Invoice ────[1:N]──────> InvoiceLine
     • Стратегия: cascade = CascadeType.ALL, orphanRemoval = true
     • Обоснование: OrderItem не существует в отрыве от Order.
     
  2. АССОЦИАЦИЯ (Связь между независимыми сущностями)
     Order ──────[N:1]──────> Customer
     Product ────[N:M]──────> Category
     • Стратегия: БЕЗ cascade (или только PERSIST/MERGE при необходимости)
     • Обоснование: Удаление заказа НЕ ДОЛЖНО удалять клиента!

🔴 Senior Level

Ловушка разделения PERSIST и MERGE

Распространенная ошибка проектирования: разработчик указывает cascade = CascadeType.PERSIST, забывая про CascadeType.MERGE:

@Entity
public class Order {
    @Id
    private Long id;

    @OneToMany(mappedBy = "order", cascade = CascadeType.PERSIST)
    private List<OrderItem> items = new ArrayList<>();
}

Что происходит в коде сервиса:

// 1. Получили detached-заказ (например, из REST API)
Order detachedOrder = getOrderFromApi();
detachedOrder.getItems().get(0).setPrice(BigDecimal.TEN);

// 2. В транзакции вызываем сохранение:
Order managedOrder = entityManager.merge(detachedOrder);
  • Поскольку у коллекции items указан только CascadeType.PERSIST, метод merge() проигнорирует дочернюю коллекцию!
  • Родитель Order обновится, но измененная цена в OrderItem не будет сохранена в базе данных!
  • Правило: Если сущность может обновляться в detached-состоянии, каскады PERSIST и MERGE практически всегда должны идти в паре: cascade = {CascadeType.PERSIST, CascadeType.MERGE} (или CascadeType.ALL).

Опасности каскада REMOVE в отношениях @ManyToMany

@Entity
public class Student {
    @Id
    private Long id;

    // ❌ КАТАСТРОФА: Удаление студента удалит все курсы из университета!
    @ManyToMany(cascade = CascadeType.ALL)
    private List<Course> courses = new ArrayList<>();
}

Если отчислить одного студента через entityManager.remove(student), Hibernate удалит не просто связующую строку в student_courses, а физически удалит строки из таблицы courses! А если у курса Course также стоял каскад ALL к студентам, Hibernate каскадно сотрет всех остальных студентов этого курса.

Стандарт: Для @ManyToMany каскад REMOVE категорически запрещен. Разрешены только PERSIST и MERGE.

4 Tricky Questions

1. Если на связи стоит только CascadeType.PERSIST, сработает ли сохранение дочернего элемента при вызове repository.save(parent) в Spring Data JPA, если родитель уже существует в БД?

Ответ:

  1. Нет, не сработает!
  2. В Spring Data JPA метод save(entity) проверяет, является ли сущность новой (isNew()).
  3. Поскольку родитель уже существует в базе (id != null), Spring Data вызывает метод entityManager.merge(parent), а не persist().
  4. Так как на связи объявлен только CascadeType.PERSIST, метод merge() не будет каскадироваться на дочерние элементы. Новые дочерние объекты останутся в состоянии Transient, и СУБД выбросит ошибку TransientPropertyValueException.

2. Что произойдет, если родительская сущность содержит каскад CascadeType.ALL на дочернюю коллекцию, но в базе данных на внешнем ключе настроено правило ON DELETE RESTRICT?

Ответ:

  1. При вызове entityManager.remove(parent) Hibernate выполнит каскадный обход и сформирует в ActionQueue список команд DELETE для каждого дочернего элемента, а затем — для родителя.
  2. Поскольку Hibernate выполняет удаление дочерних записей раньше, чем родительской строки, ограничение базы данных ON DELETE RESTRICT не будет нарушено, и удаление завершится успешно.
  3. Ошибка СУБД возникла бы только в том случае, если бы удаление выполнялось прямым нативным SQL-запросом к родителю без предварительной зачистки детей.

3. Допустим, мы вызываем entityManager.refresh(parent), а на связи указан CascadeType.REFRESH. Что произойдет с несохраненными изменениями в дочерних объектах?

Ответ:

  1. Каскад REFRESH распространится на каждую дочернюю сущность, находящуюся в памяти.
  2. Для каждого дочернего объекта Hibernate выполнит SQL SELECT * FROM child_table WHERE id = ?.
  3. Все несохраненные локальные изменения, сделанные в полях дочерних объектов в оперативной памяти JVM, будут безвозвратно стерты актуальными значениями колонок из базы данных.

4. Почему каскад CascadeType.DETACH не защищает от LazyInitializationException после закрытия сессии?

Ответ:

  1. CascadeType.DETACH переводит объекты из состояния Managed в Detached.
  2. Если связанная ленивая коллекция не была загружена в память до вызова detach(), она так и остается неинициализированным прокси-объектом PersistentBag.
  3. Поскольку сессия отсоединяется, прокси теряет доступ к активному JDBC-соединению.
  4. Последующее обращение к геттеру коллекции на отсоединенном объекте гарантированно выбросит LazyInitializationException. Каскад DETACH управляет статусом сущностей в контексте, но не форсирует загрузку данных из базы.

🎯 Шпаргалка для интервью

30-секундный ответ (Elevator Pitch)

«В JPA существует 6 типов каскадов (CascadeType): PERSIST, MERGE, REMOVE, REFRESH, DETACH и ALL. Главный архитектурный принцип выбора каскадов основан на концепции агрегатов DDD: для композиций @OneToMany (где дочерние объекты не имеют смысла без родителя, как Order -> OrderItem) используется связка CascadeType.ALL вместе с orphanRemoval = true. Для ассоциаций @ManyToOne и @ManyToMany (где сущности независимы) каскад REMOVE строго запрещен во избежание удаления разделяемых данных. Важно помнить, что PERSIST и MERGE действуют независимо: если в Spring Data JPA вызвать save() на существующем родителе с каскадом только PERSIST, дочерние объекты не сохранятся».

Ключевые метрики для Production-мониторинга

  • Cascade Tree Traversal Depth: глубина каскадного обхода графа объектов (слишком глубокие деревья замедляют коммит транзакции).
  • Количество SQL-операций на один вызов save() / remove(): позволяет вовремя обнаружить избыточный каскадный оверхед.

Красные флаги (Чего говорить НЕЛЬЗЯ)

  • ❌ «Я всегда ставлю CascadeType.ALL на все аннотации @ManyToOne» — Это приведет к удалению пользователей или справочников при удалении дочерних записей.
  • ❌ «CascadeType.PERSIST автоматически включает в себя и CascadeType.MERGE» — Ложь. Это абсолютно независимые операции жизненного цикла.
  • ❌ «Каскад REMOVE на связи @ManyToMany удалит только связующую таблицу» — Нет, он физически удалит целевые сущности из их основных таблиц.
  • ❌ «Использую CascadeType.ALL для связи Order -> Customer» — Нарушение границ агрегатов, заказ не владеет клиентом.

Связанные темы