TransientObjectException on persistent entity in CascadingActions CHECK_ON_FLUSH

Description

Hi, I believe there’s a bug with the new logic of detecting transient entities when flushing the context.

We have gotten to it while upgrading our codebase to JDK 17 and Hibernate 6.6.0 with Spring 6.

How to reproduce?

The simplified case in our code is that we have two entities with a hibernate only ManyToOne relationship between them, in order to have a convenient way of writing joins, however, in the database, the two entities have no foreign key relationship, as one is a ‘'live entry’' and another a ‘'archive of changes’' that has an id of the live entry but for obvious reasons cannot be connected to it.

We get the TransientObjectException in the case of inserting the archived entry, while deleting the live entry.

The reason is the recent changes to the CHECK_ON_FLUSH action:

The snippet has the the isTransient method with the new logic as of 6.6.0, and the problem is the check for deleted or gone. The older logic also has that check, however it did not just exit the method if it was deleted or gone, it would also check the isTransient from ForeignKeys.

In this case that check would for a non version entity check the Identity strategy (NULL) and return false as it’s assumed that all existing entities in context are assumed not transient:

We believe that the change introduced in the fix of

broke the old behaviour. We believe the transient checks should be performed on ‘'deleted’' entries as some of them are ‘'persistent’' in the context of said transaction as they are waiting to be deleted in that same transaction.

Attachments

Activity

Show:

Tin Babić October 22, 2024 at 9:11 PM

It would appear that the side effect truly was from a fragment of our own code misbehaving, unrelated to hibernate itself, as I did not run the specific case in the test cases project to double check.

The removal of the relationship prior to committing the transaction does indeed preserve the IDParent while not giving us the error in 6.6.0.

I apologise for taking your time and we will modify our code base to address the errors on our end.

This issue can be closed.

Gavin King October 22, 2024 at 3:09 PM

he side effect is that the IDParent field in the TestArchive entity get nullified as well

It’s very hard to believe that this would happen. Hibernate simply doesn’t work like that.

Anyway, I just ran your code, with the suggested modification, and the idparent field was not set to null.

Everything behaved exactly as I would expect.

Tin Babić October 22, 2024 at 2:20 PM

Hi, thanks for a quick reply, yes we have tried setting the parent logical relationship to null, at which point the transaction with removal succeeds, however the side effect is that the IDParent field in the TestArchive entity get nullified as well, which doesn’t accurately represent the DB situation we wish to achieve.

I have included the test cases which show the hibernate 5 vs 6.4.2 vs 6.6.0 behaviour. If I reduce the hibernate version to 6.4.2 (the test case has it set to that version) the behaviour is consistent with the hibernate 5.

Gavin King October 21, 2024 at 8:13 PM

Two things:

I don’t completely understand what you’re doing but it looks to me like Hibernate is functioning correctly, and you need to call archive.settestParent(null) before deleting the parent, since the association would have been loaded when you called refresh().
If you disagree, you need to provide a simple runnable test.