Issue #2280: Query in nested transaction returns detached entity if lazy-loaded

Hello,

we've encountered an issue with ObjectDB. The attached code is a minimal example of the relevant work flow and fails at the assert in line 58: assertTrue(secondQueryResult.get(1).strValue != null); The entity is detached and data is not loaded lazily from the database. We've also found that this issue only occurs, when a first query is present (lines 36-39).

Can you please verify this issue and provide us with some advise?

Best wishes,

BTC-ES team

Increased priority to critical...

We can confirm that your test case demonstrates a strange behaviour, we are working on it.

Still working on it. Hopefully a solution will be available soon.

Your test case demonstrates a bug in retrieving new objects that have been persisted by other transactions from within a transaction that was flushed before these objects have been persisted.

This is caused due to the way that currently ObjectDB manages flushed transactions as a snapshot of the database when flush occurs.

Build 2.7.4_04 includes a workaround that updates the snapshot when a query is executed.

Thanks for fixing the issue! It works fine now.

Hello,

if we use the version 2.7.4_04 then we get another issues in our test suites.

We worked on enhanced classes.

We activated the entity listeners for pre persisted and post persisted in order to check the entity version number.

For example a new entity is created (entity version = 0), pre persisted (entity version = 0), post persisted (entity version = 1) and committed, during the commit an optimistic lock exception is thrown. The version flag of the entity was unexpectedly incremented and caused the exception.

But if we use the former ObjectDB version 2.7.4_03 then our test suite performs again, we don't get strange effects.

Unfortunately The version 2.7.4_04 is not usable in our tool.

Caused by: com.objectdb.o._RollbackException: Failed to commit transaction: Optimistic lock failed for object com.btc.ep.base.bl.internal.entities.mapping.MappingImpl#'2BO' (object has version 2 instead of 1) [MappingImpl:'2BO']
    at com.objectdb.o.JPE.d(JPE.java:91)
    at com.objectdb.o.ERR.h(ERR.java:56)
    at com.objectdb.o.OBC.onObjectDBError(OBC.java:1582)
    at com.objectdb.jpa.EMImpl.commit(EMImpl.java:289)
    at com.btc.ep.base.transactions.internal.TransactionManagerImpl.lambda$1(TransactionManagerImpl.java:313)
    at java.util.Optional.ifPresent(Optional.java:159)
    at com.btc.ep.base.transactions.internal.TransactionManagerImpl.doCommit(TransactionManagerImpl.java:311)
    ... 45 more
Caused by: com.objectdb.o._OptimisticLockException: Optimistic lock failed for object com.btc.ep.base.bl.internal.entities.mapping.MappingImpl#'2BO' (object has version 2 instead of 1) [MappingImpl:'2BO']
    at com.objectdb.o.JPE.d(JPE.java:135)
    at com.objectdb.o.JPE.d(JPE.java:80)
    ... 51 more

Best regards,

BTC-ES team

Could you please amend the previous test program to demonstrate the new exception?

In response to the last comment from https://www.objectdb.com/forum/2333 I would like to point out that reverting the changes made in 2.7.4_04 would re-introduce the original bug with nested transactions. We'd welcome it, if you were able to find a solution that also solves the initial bug :)

After further examination it seems that the change in version 2.7.4_04 that solves this issue is essential and should remain. It isn't clear yet where it fails. We should discuss it back in issue #2333.