Issue #2089: Removing of an entity removes also another entity type

Hello,

we have following case:

All entities must be enhanced, because see Issue #303.

ToleranceDefinition and ResolverMapping are entities and have not any relations each other.

Before start transaction the ToleranceDefinition entities exist already in the database.

The transaction starts. All ResolverMapping entities are removed by a query (DELETE FROM ...), afterwards ResolverMapping entities are created and persisted again. The ResolverMapping entities are retrieved from database by a query with a result and after that a ToleranceDefinition entity is removed from database by entitymanager.remove(obj). Directly after remove we try to retrieve again the ResolverMapping entities from database and we get an empty result.

This is a data lost, why this behavior can occurs?

Please provide a minimal runnable test (in this format) that demonstrates this issue.

We have found a workaround for this issue, but this is not a bug fix.

If the ToleranceDefinition entity is removed from database by a query (DELETE FROM ...) then it performs. The data is not lost.

This workaround prevent also the Issue #303. Tested with 2.7.1, 2.7.1_02 and the newest 2.7.1_03.

OK. Thanks for the update.

Please note that mixing direct DELETE / UPDATE database queries with EntityManager's operations is known as problematic. It is not specific to ObjectDB but general to JPA. DELETE / UPDATE JPA queries bypass the EntityManager mechanism and therefore are very risky as the EntityManager can easily loss synchronization with the database.

If you use direct DELETE / UPDATE queries it should be done using a separate EntityManager. So your workaround is actually the correct way of using DELETE / UPDATE queries in JPA by isolating them from conflicting EntityManager operations.

See also this relevant paragraph in the ObjectDB manual:

Updating entity objects in the database using an UPDATE query may be slightly more efficient than retrieving entity objects and then updating them, but it should be used cautiously because bypassing the EntityManager may break its synchronization with the database. For example, the  EntityManager may not be aware that a cached entity object in its persistence context has been modified by an UPDATE query. Therefore, it is a good practice to use a separate EntityManager for UPDATE queries.

So this issue is not a bug and will be closed.

We will try to implement an example for this issue.

It was not possible to implement an small example, since the issue occurs only in a big context.

But we found the reason of this issue.

We used one transaction and our entities are all enhanced.

DELETE FROM ResolverMapping

em.persist(new ResolverMapping()); // persist some new ResolverMappings

DELETE FROM ToleranceDefinition

SELECT rm from ResolverMapping WHERE rm.type = 'interfaces' // there are also other types like 'scopes'

em.remove(toleranceDefinition); // the 'attached' ToleranceDefinition entity was already removed by 'DELETE FROM ToleranceDefinition', but it works without exception

SELECT rm from ResolverMapping WHERE rm.type = 'interfaces' // now the ResolverMappings with type = 'interfaces' are not available anymore, the result is empty, only the ResolverMappings with type = 'scopes' are still available in the database

Why the ResolverMappings with type = 'interfaces' are removed? I would expect problems with ToleranceDefinition entities, but not with lost ResolverMappings, if a ToleranceDefinition was removed by em.remove(toleranceDefinition).

If we replace the 'DELETE FROM ToleranceDefinition' operation by many em.remove(toleranceDefinition) operations then it works well and the ResolverMappings with type = 'interfaces' are still available.

Please note that mixing direct DELETE / UPDATE database queries with EntityManager's operations is known as problematic. It is not specific to ObjectDB but general to JPA. DELETE / UPDATE JPA queries bypass the EntityManager mechanism and therefore are very risky as the EntityManager can easily loss synchronization with the database.

If you use direct DELETE / UPDATE queries it should be done using a separate EntityManager.

See also this relevant paragraph in the ObjectDB manual:

Removing entity objects from the database using a DELETE query may be slightly more efficient than retrieving entity objects and then removing them, but it should be used cautiously because bypassing the EntityManager may break its synchronization with the database. For example, the  EntityManager may not be aware that a cached entity object in its persistence context has been removed from the database by a DELETE query. Therefore, it is a good practice to use a separate EntityManager for DELETE queries.