TransientObjectException when mixing EntityManager.delete with delete statements in 6.6.x

[papegaaij]

@mbladel

Hey @papegaaij, there are a few things wrong with your comments:

@papegaaij

Here you can see 2 entities being persisted in the database, one referencing the other. At some later point, we want to delete other, therefore we also need to delete all entities referencing that other

That is not correct, unless your application logic implies it (and so it would be needed anyway), you don’t need to delete entities referring to the removed one, but simply to remove references to the latter: setting to-one associations to null and / or removing removed entities from associated collections.

Yes of course, you can also nullify references. However, in this case, the reference is not null, hence the other side of the relation must also be removed. This particular case is about access tokens for an account. Every access token has an account associated, it must have. Removing the account, requires the removal of all access tokens (which could be many). We’ve also got similar cases where we can nullify the reference. However, this faces the exact same issue: setting the column to null via a CriteriaUpdate does not change the value of the property on managed entities (for obvious reasons), triggering the same TransientObjectException when performing the flush.

The cause of the issue is that a CriteriaDelete does not remove entities from the EntityManager in the same way that a CriteriaUpdate does not update entities managed by the EntityManager. The EntityManager therefore is very likely to maintain stale state after such a statement.

@mbladel

The transient check is only executed against persistent entities: i.e., instances you have already loaded in your persistence context. You will never need to load additional entity instances to fulfill this requirement, as Hibernate cannot do this check on non-existent entity instances.

You can only call EntityManager.detach with a managed entity. Therefore, you must load entities in other to detach them. Going back to the example with the access tokens: if you do not know which access tokens for a given account are currently managed by the EntityManager and want to make sure the EntityManager does not manage any of these tokens, you need to do a query, load them and detach them. If you know any other way of detaching entities without any knowledge of the current content of the EntityManager, please let me know.

@mbladel

The only alternative to having to manually manage bi-directional associations is to have bytecode enhancement enabled and use bidirectional association management.

This question has nothing to do with bi-directional associations. The example is uni-directional. We do use bytecode enhancement, but only for dirty tracking. We’ve got other code in place to manage bi-directional associations. However, this is about uni-directional associations: the account does not have a list of its access tokens. That would not make much sense and it would be way too expensive to load into memory anyway.

The change in behavior in Hibernate 6.6.0 breaks our application in quite a few places and I really see no way of fixing the issue. It seems I can no longer rely on CriteriaUpdate and CriteriaDelete to maintain referential integrity when deleting entities. Both require me to detach any entity the EntityManager might be holding that is affected by these statements, however the EntityManager does not provide an API to do this, other than clearing the entire EntityManager or detaching all affected entities one by one (which requires loading them first).