Hibernate complains about orphan removal for empty and untouched collection

Question

Update: In the meantime, I opened an issue HHH-15512 in the hibernate tracker.

I was recently forced to upgrade Hibernate from 5.x to 6.x and I am using the currently most recent version 6.1.2.Final.

Among the things that broke apart is that I have a parameterized test case that gets instantiated four times and doing something with a Entity. In only two of the four instances, committing the transaction results in the following error:

A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance

The relevant part of the entity is this:

public class MyEntity {
    @LazyCollection(LazyCollectionOption.TRUE)
    @Cascade(CascadeType.ALL)
    @OnDelete(action = OnDeleteAction.CASCADE)
    @OneToMany(orphanRemoval = true, mappedBy = "parent")
    private final List<ChildOne> childOnes = new ArrayList<>();

    @LazyCollection(LazyCollectionOption.TRUE)
    @Cascade(CascadeType.ALL)
    @OnDelete(action = OnDeleteAction.CASCADE)
    @OneToMany(orphanRemoval = true, mappedBy = "parent")
    private final List<ChildTwo> childTwos = new ArrayList<>();
}

Of course it has many other attributes and collections, but the relevant part are two collections here.

The test case modifies one of them - childOnes. The hibernate exception complains about the other collection - childTwos. But that collection is never touched in the entire test case.

The test case goes like this (simplified):

    @BeforeEach
    void openDatabaseSession() {
        dbTx = sfp.beginTransaction();
    }

    @AfterEach
    void closeDatabaseSession() {
        dbTx.commit();
    }

    @ParameterizedTest
    @MethodSource("irrelevantSource")
    void doTest(/* some irrelevant params */) {
        final var child = new ChildOne();
        // given
        final var e = new MyEntity();
        e.addChildOne(child);
        sfp.getCurrentSession().save(e);

        // when
        final var result = service.someMethod(e); // not altering childTwos!

        // then
        final var testee = sfp.getCurrentSession().find(MyEntity.class, e.getId());
        assertNotNull(testee);
        var c = testee.getChildOnes();
        // ... some assertions ...
    }

I see that reloading the entity into a separate testee seems somehow redundant, but the error also occurs when I remove that and work with the original e.

I have already tried to debug the problem and found the following Hibernate code in Hibernate's Collections.java:

final EntityEntry e = persistenceContext.getEntry( owner );
//only collections belonging to deleted entities are allowed to be dereferenced in the case of orphan delete
if ( e != null && e.getStatus() != Status.DELETED && e.getStatus() != Status.GONE ) {
    throw new HibernateException(
            "A collection with cascade=\"all-delete-orphan\" was no longer referenced by the owning entity instance: " +
                    loadedPersister.getRole()
    );
}

The debugger tells me that e.getStatus() == Status.MANAGED, which is obviously the root cause of the Exception.

But why is Hibernate even trying to perform orpahn removal on a completely untouched and never used collection? And why does Hibernate perform orphan removal on a collection that is apparently the child of a still managed entity?

And more interestingly: why does Hibernate only complain in two out of the four test case instances? They all do the same (at least regarding the collection Hibernate complains about).

And what can be done to fix that? I am currently thinking about just removing orphanRemoval=true everywhere but I resist to believe, that this Hibernate feature is just broken and it would take huge effort to delete the orphans manually... So it's not a real option.

Answer 1

Okay, I found the "solution".

Hibernate obviously evolved a bit and is more and more JPA compliant. Therefore save() is deprecated and the suggestion is to use persist(). But that's only half the truth, because a persist() needs a flush() while save() always guaranteed that you can obtain a generated ID e.g. That is why you do not see a flush() in the above code.

But that's not the point.

The point is, that the service method in the test case used a HQL query in two out of the four cases to retrieve the entity e. One would assume that this is the same object and it really is! And obviously this all has nothing to do with orphan removal or the collection, Hibernate complains about. But Hibernate does seem to have a valid and consistent state after this query is executed.

So I assume that the query, that retrieves e does pollute the persistence context somehow and there is some messed up state regarding e that was previously saved via save().

A flush() after save() "fixes" the problem, although I don't have a clue why and how and why it worked in previous Hibernate versions without the flush()...

So maybe, just maybe, it is a bug in hibernate. But maybe it's just that some semantic rules have become a bit stricter than they were in the past and it is desired behavior now and just worked accidentally in previous versions. Who knows...