Issue #2086: Error during closing an entity manager

Hello, can you explain the the following exception?

Caused by: com.objectdb.o._PersistenceException: Failed to read the value of field field com.btc.ep.architecture.bl.internal.dmos.types.NormalizedAccessPathImpl.accessPathRoot using reflection
at com.objectdb.o._PersistenceException.b(_PersistenceException.java:45) ~[na:na]
at com.objectdb.o.JPE.g(JPE.java:145) ~[na:na]
at com.objectdb.o.ERR.f(ERR.java:56) ~[na:na]
at com.objectdb.o.OBC.onObjectDBError(OBC.java:1560) ~[na:na]
at com.objectdb.o.OBM.close(OBM.java:212) ~[na:na]

More information is needed:

• Please check the log file for a longer stack trace (as this looks as a partial stack trace).
• Can you reproduce the exception? Is it always thrown, in some specific cases or randomly?
• Anything that was changed in your application recently that could cause it? e.g. schema change?

Here is the full stacktrace:

Caused by: com.objectdb.o._PersistenceException: Failed to read the value of field field com.btc.ep.architecture.bl.internal.dmos.types.NormalizedAccessPathImpl.accessPathRoot using reflection
at com.objectdb.o._PersistenceException.b(_PersistenceException.java:45) ~[na:na]
at com.objectdb.o.JPE.g(JPE.java:145) ~[na:na]
at com.objectdb.o.ERR.f(ERR.java:56) ~[na:na]
at com.objectdb.o.OBC.onObjectDBError(OBC.java:1560) ~[na:na]
at com.objectdb.o.OBM.close(OBM.java:212) ~[na:na]
at com.btc.ep.base.transactions.internal.TransactionManagerImpl.lambda$4(TransactionManagerImpl.java:395) ~[na:na]
at com.btc.ep.base.transactions.internal.TransactionManagerImpl$$Lambda$136/1694039801.accept(Unknown Source) ~[na:na]
at java.util.Optional.ifPresent(Optional.java:159) ~[na:1.8.0_51]
at com.btc.ep.base.transactions.internal.TransactionManagerImpl.doClose(TransactionManagerImpl.java:395) ~[na:na]
... 7 common frames omitted
Caused by: com.objectdb.o.UserException: Failed to read the value of field field com.btc.ep.architecture.bl.internal.dmos.types.NormalizedAccessPathImpl.accessPathRoot using reflection
at com.objectdb.o.MSG.d(MSG.java:75) ~[na:na]
at com.objectdb.o.UMR.P(UMR.java:937) ~[na:na]
at com.objectdb.o.UMR.B(UMR.java:612) ~[na:na]
at com.objectdb.o.UML.v(UML.java:549) ~[na:na]
at com.objectdb.o.MMM.ak(MMM.java:1164) ~[na:na]
at com.objectdb.o.UTY.aF(UTY.java:1483) ~[na:na]
at com.objectdb.o.UTY.aD(UTY.java:1410) ~[na:na]
at com.objectdb.o.ENH.b(ENH.java:102) ~[na:na]
at com.objectdb.o.LDR.L(LDR.java:830) ~[na:na]
at com.objectdb.o.LDR.Vz(LDR.java:1061) ~[na:na]
at com.objectdb.o.RTT.G(RTT.java:267) ~[na:na]
at com.objectdb.o.RTT.F(RTT.java:249) ~[na:na]
at com.objectdb.o.RST.C(RST.java:180) ~[na:na]
at com.objectdb.o.RTT.l(RTT.java:134) ~[na:na]
at com.objectdb.o.RST.l(RST.java:24) ~[na:na]
at com.objectdb.o.RTT.D(RTT.java:179) ~[na:na]
at com.objectdb.o.RST.s(RST.java:121) ~[na:na]
at com.objectdb.o.PGT.q(PGT.java:109) ~[na:na]
at com.objectdb.o.RST.B(RST.java:93) ~[na:na]
at com.objectdb.o.RTT.l(RTT.java:132) ~[na:na]
at com.objectdb.o.RST.l(RST.java:24) ~[na:na]
at com.objectdb.o.TSK.i(TSK.java:145) ~[na:na]
at com.objectdb.o.TSK.f(TSK.java:95) ~[na:na]
at com.objectdb.o.MST.a0(MST.java:609) ~[na:na]
at com.objectdb.o.MST.U7(MST.java:565) ~[na:na]
at com.objectdb.o.WRA.U7(WRA.java:279) ~[na:na]
at com.objectdb.o.LDR.G(LDR.java:583) ~[na:na]
at com.objectdb.o.LDR.F(LDR.java:473) ~[na:na]
at com.objectdb.o.OBC.U2(OBC.java:1101) ~[na:na]
at com.objectdb.o.ENT.d(ENT.java:1182) ~[na:na]
at com.objectdb.o.ENT.extractCollection(ENT.java:1555) ~[na:na]
at objectdb.java.util.ArrayList.__odbBeforeAccess(Unknown Source) ~[na:na]
at objectdb.java.util.ArrayList.iterator(Unknown Source) ~[na:na]
at com.objectdb.o.ENT.D(ENT.java:419) ~[na:na]
at com.objectdb.o.ENT.D(ENT.java:431) ~[na:na]
at com.objectdb.o.ENT.D(ENT.java:502) ~[na:na]
at com.objectdb.o.ENT.D(ENT.java:385) ~[na:na]
at com.objectdb.o.STA.af(STA.java:838) ~[na:na]
at com.objectdb.o.STM.D(STM.java:371) ~[na:na]
at com.objectdb.o.OBC.ag(OBC.java:200) ~[na:na]
at com.objectdb.o.OBM.close(OBM.java:198) ~[na:na]
... 11 common frames omitted
Caused by: java.lang.NullPointerException: null
at com.objectdb.o.OBC.az(OBC.java:468) ~[na:na]
at com.objectdb.o.OBC.aN(OBC.java:958) ~[na:na]
at com.objectdb.o.OBC.UZ(OBC.java:822) ~[na:na]
at com.objectdb.o.TYR.aF(TYR.java:715) ~[na:na]
at com.objectdb.o.TYR.completeRead(TYR.java:562) ~[na:na]
at com.objectdb.o.TYR.readElement(TYR.java:294) ~[na:na]
at com.objectdb.o.UTY.readAndAdjust(UTY.java:1585) ~[na:na]
at com.objectdb.o.UMR$S.C(UMR.java:1018) ~[na:na]
at com.objectdb.o.UMR.B(UMR.java:606) ~[na:na]
... 49 common frames omitted

We have found a workaround. We have just enhanced the entities and then it works as intended.

But why this case does not perform without enhanced entities?

The exception may be due to having partial enhancement.

Mixing enhanced entity classes with non enhanced entity classes in the same class hierarchy is not supported.

But we have done a full clean and build of our entity classes and there cannot be any enhanced entites and in this case we get the full stack trace of #3.

In that case it is a bug. Do you have a way to reproduce it?

i.e. if we release a build with an attempt to fix it would you be able to check it?

Yes, we can reproduce it. I tried also newest version 2.7.1_02, but the error throws again.

Could you please check build 2.7.1_03?

I have a further hint. We have found a workaround for Issue #306 and this workaround prevents also this issue, so that the enhancement is not necessary.

We tested also 2.7.1_03 and with this one we get an optimistic lock exception without enhancement. If we enhance all entities then the issue does not occur, but we still always lose data how described in Issue #306 without the workaround of Issue #306.

I think Issue #303 and Issue #306 belonging together.

Let's focus here with this issue and not with issue #2089, which has a separate space.

Apparently the new build changed the exception from the one in #3 above to an optimistic lock exception. More information and possibly a test case that demonstrates the exception will be needed to explore this further.

But enhancement is definitely preferred is production, and a must in OEM applications (for distributing your application to clients with no need to activate ObjectDB), so enhancement should probably be your priority now.

We have found the reason of the optimistic lock exception and we fixed it in our code. From my sight of view this issue is fixed.