ObjectDB ObjectDB

Error during closing an entity manager

#1

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]

edit
delete
#2

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?
ObjectDB Support
edit
delete
#3

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
edit
delete
#4

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?

edit
delete
#5

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.

ObjectDB Support
edit
delete
#6

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.

edit
delete
#7

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?

ObjectDB Support
edit
delete
#8

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

edit
delete
#9

Could you please check build 2.7.1_03?

ObjectDB Support
edit
delete
#10

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.

edit
delete
#11

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.

edit
delete
#12

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.

ObjectDB Support
edit
delete
#13

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.

edit
delete

Reply

To post on this website please sign in.