Issue #527: TYE NullPointerException

I've been seeing the following stack trace in a couple of tests today:

java.lang.NullPointerException
at com.objectdb.o.TYR.<init>(TYR.java:104)
at com.objectdb.o.ENT.newTypeReader(ENT.java:1258)
at com.objectdb.o.TYT.extractCollection(TYT.java:41)
at com.objectdb.o.ENT.extractCollection(ENT.java:1306)
at objectdb.java.util.ArrayList.__odbBeforeAccess(Unknown Source)
at objectdb.java.util.ArrayList.iterator(Unknown Source)
at rbccm.digest2.execution.ExecutionGraph.<init>(ExecutionGraph.java:133)
at rbccm.digest2.execution.Workflow2Runner.processWorkflows(Workflow2Runner.java:122)
at rbccm.digest2.execution.Workflow2Runner.workflowCompleteForSomeTasks(Workflow2Runner.java:298)
at rbccm.digest2.test.utility.LocalThreadDispatcher$DispatchRunner.run(LocalThreadDispatcher.java:63)
at java.lang.Thread.run(Thread.java:595)

I dont have a simple test to recreate it at the moment as I think it will go away when I fix something in the test itself but I can put one together if the stack trace isn't enough to highlight the problem.

The exception is thrown on an attempt to use a lazy collection that has not been loaded in a detached entity object. Build 2.3.1_03 should fix the exception (but notice that the data will not be available and the collection would look empty - if it has not been loaded before detachment).

If an unexpected exception (e.g. NullPointerException or ClassCastException) is thrown by ObjectDB - posting the full stack trace may be sufficient to locate the problem, so at least as a first step - no sample program has to be provided. The posting instructions have been updated accordingly.

Thank you for this bug report.

Thanks for that.

Its interesting you mention the entity is detached though as that wasnt the intention in this case - the EntityManager is still open and no explicit detach is called. Is there another way in which an object can become detached?

Perhaps a similar issue I've been seeing is related. I have a class with a collection property, this is defined as Collection<String> and is backed by LinkedList<String>. The class has a method which throws an exception if this collection doesnt contain a given string, i.e.

if(!collection.Contains(somestring))
    throw new Exception("Not found");

In tests the exception was being thrown even though the collection should contain the item. Again the object is not explicitly detached and the EntityManager is kept open. Putting a breakpoint on the throw line confirmed that the collection contained the relevant data so it looked like object wasn't loaded for the check but by looking at it in the debugger a load was forced.

I put a simple loop iteration in front of the check to force a load (and prove the object was not detached) and could not recreate the problem. I've now added a FetchType of EAGER to the member to ensure a load takes place regardless of attached status and again the problem has not re-occured.

I'll see if I can recreate the problem with a simple example. The observed behaviour wasnt consistent so I think there may be problem in my app which could be causing it rather than objectdb itself but I thought I'd raise it here anyway in case it triggers any thoughts.

Actually, now that you mention it I think that the object was not detached because on detachment ObjectDB collections are replaced with ordinary Java collections, so this exception is not expected.

Still, the collection lost its connection to the EntityManager.

I can think about another situation that may cause it - using a collection field of an entity object that has been garbage collected. If this is the case - it may explain inconsistency.

Is it possible that your application uses a collection after it releases the last strong reference to the containing entity object?

Following issue #544 - a better fix is included now in build 2.3.2_01.

Lazy collections will always hold a strong reference to the containing entity - so this unexpected state would be avoided.