An entity mapped with @OneToMany(orphanRemoval = true) is detached, its child collection is replaced with a brand-new ArrayList rebuilt from an incoming payload, and the entity is merged back. What can go wrong, and why does Hibernate care which collection instance the entity holds?

## Hibernate owns the collection object, not just its contents When you load an entity with a mapped collection, Hibernate does not keep the `ArrayList` you constructed in the field initialiser. It replaces the field value with a subclass-like wrapper implementing `PersistentCollection` — `PersistentBag` for a `List`, `PersistentSet` for a `Set`, and so on. This wrapper does three jobs: it lazily triggers loading on first access, it records the collection's loaded snapshot for dirty checking, and it holds a back-reference to the owning entity and the role of the association. Orphan removal is implemented on top of that bookkeeping: at flush, Hibernate compares the current contents with the snapshot and, for a collection declared `orphanRemoval = true`, schedules DELETEs for every child that left. This explains the otherwise cryptic behaviour that follows. ## Failure one: replacing the collection instance ```java parent.setChildren(new ArrayList<>(fromRequest)); // field now holds a plain list ``` For a plain association this is merely wasteful (Hibernate treats it as “all old elements removed, all new elements added” and may delete-and-reinsert every row). For an association with orphan removal it is an error: the wrapper Hibernate was tracking is no longer reachable from the entity, so it cannot decide which children became orphans, and it refuses with `A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance`. The rule to memorise: **never reassign a mapped collection field on a managed entity**. Mutate it — `clear()` then `addAll()`, or add/remove individual elements. A defensive habit is to expose only `addChild`/`removeChild` methods and keep the field private with no setter. Detachment and serialization make this easy to hit accidentally. A JSON deserializer building the entity from a request body constructs a fresh `ArrayList`; a `clone()`/copy-constructor does the same; some mapping frameworks call the setter unconditionally. The moment that object is merged onto a managed parent, the assignment happens inside merge’s copy step, on the managed instance. ## Failure two: the incoming collection is read as the whole truth This one produces no exception and is the reason detached graphs are dangerous as write payloads. Merge copies collection state too, so after the copy the managed parent’s collection contains exactly the children you sent. Anything the database had and your list lacks is, by definition, no longer referenced — an orphan — and with `orphanRemoval = true` Hibernate DELETEs it at flush. Realistic ways to send an incomplete list: - The client only displayed and returned a page of children. - A serializer omitted elements (filtered by permissions, or by a view/projection). - The detached object was built by a mapper that skipped the association entirely, sending an empty list. - The graph crossed a boundary that dropped elements it could not deserialize. All of them read as “delete these rows”. Note the asymmetric case: if the collection on the detached instance is an **uninitialized** lazy proxy — it was never touched before detaching, and it is still Hibernate’s wrapper — merge leaves the association alone rather than assuming emptiness. That is a narrow safety net that disappears the moment the graph is serialized, because serialization turns the wrapper into a plain (often empty) list. ## Related traps in the same family - **Bidirectional consistency.** Removing a child from the parent list while the child still points to the parent, or vice versa, gives you a delete that does not happen or a foreign key that is not cleared. Maintain both sides in the add/remove helpers. - **Set semantics and equality.** Rebuilding children as new objects means new identity; if the collection is a `Set` relying on a business-key `equals`/`hashCode`, a sloppy implementation makes Hibernate see “every element removed, every element added” and delete-and-reinsert the lot, burning ids and breaking anything referencing them. - **orphanRemoval versus cascade REMOVE.** Orphan removal fires when a child is *dereferenced* from the parent collection; cascade REMOVE fires when the *parent itself* is deleted. Only the former is triggered by the merge scenarios above. ## The pattern that avoids all of it Do not send entity graphs in for writes. Inside the transaction, load the managed parent, then reconcile against the incoming DTO list by identifier: update matched children in place, add the ones with no identifier, and remove only those the request explicitly says to remove (or those absent, if and only if the contract genuinely means “this is the full list”). Dirty checking then generates exactly the statements you intended, and the destructive default — absent means delete — becomes an explicit, reviewable decision.