What causes "queued clear cannot be used with orphan delete" in hibernate/hibernate-orm?

Initialize the collection before clearing: Hibernate.initialize(owner.getItems()) inside the open session

hibernate/hibernate-orm · error · UnsupportedOperationException

queued clear cannot be used with orphan delete

Error message

queued clear cannot be used with orphan delete

What it means

Operations on an uninitialized collection are queued and replayed at initialization; ClearDelayedOperation records a wholesale clear. Queued operations must expose added/orphan elements for orphan-delete cascades, but a bulk clear cannot enumerate individual orphans, so getOrphan throws UnsupportedOperationException. The error appears when a lazy bag with orphanRemoval is cleared before initialization and the flush then asks the queued clear for its orphans.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/collection/spi/PersistentBag.java:675

	@Override
	public int hashCode() {
		return super.hashCode();
	}

	final class Clear implements DelayedOperation<E> {
		@Override
		public void operate() {
			collection.clear();
		}

		@Override
		public E getAddedInstance() {
			return null;
		}

		@Override
		public E getOrphan() {
			throw new UnsupportedOperationException( "queued clear cannot be used with orphan delete" );
		}
	}

	final class SimpleAdd extends AbstractValueDelayedOperation {

		public SimpleAdd(E addedValue) {
			super( addedValue, null );
		}

		@Override
		public void operate() {
			// Delayed operations only work on inverse collections i.e. collections with mappedBy,
			// and these collections don't have duplicates by definition.
			// Since cascading also operates on delayed operation's elements,
			// it can happen that an element is already associated with the collection after cascading,
			// but the queued operations are still executed after the lazy initialization of the collection.
			// To avoid duplicates, we have to check if the bag already contains this element
			if ( !collection.contains( getAddedInstance() ) ) {

View on GitHub (pinned to fad1729dce)

Solutions

Initialize the collection before clearing: Hibernate.initialize(owner.getItems()) inside the open session
Implement replacement as explicit remove/add on an initialized collection, or delete children via query
Reconsider orphanRemoval on inverse collections that are routinely cleared wholesale
Upgrade Hibernate - orphan handling for queued operations has improved across releases

Example fix

// before
order.getLines().clear();      // uninitialized bag + orphanRemoval = true
order.getLines().addAll(newLines);

// after
Hibernate.initialize(order.getLines()); // inside the session
order.getLines().clear();
order.getLines().addAll(newLines);

Defensive patterns

Strategy: validation

Validate before calling

if (order.getLines() instanceof PersistentCollection pc && !pc.wasInitialized()) {
    Hibernate.initialize(order.getLines()); // queued clear() is unsafe with orphanRemoval
}
order.getLines().clear();

Prevention

Initialize lazy collections before structural rewrites like clear()
Prefer explicit child deletion for orphanRemoval collections over clear-and-refill
Guard 'clear + refill' helper methods with an initialization check

When it happens

Trigger: Calling collection.clear() on an uninitialized @OneToMany(orphanRemoval = true) bag and then flushing or merging; detached entities whose lazy inverse collections are cleared before reattachment; test fixtures rewriting collections wholesale before load.

Common situations: 'Replace all children' implemented as clear() plus addAll() on lazy inverse collections; orphanRemoval enabled for convenience on bags; merge flows over detached graphs.

Related errors

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/97decb435025a1d0. Report an issue: GitHub.