ODB-FileWriter holds unecessary entity reference after transaction and entity manager are closed

Hello,

we've encountered a problem leading to memory leaks. We found that after closing a transaction (including the entity manager) the ODB file writer still holds a reference to entities. Performing similar calls repeatedly hence increases the number of references to entities not longer needed in the application context. This prevents the garbage collector from cleaning up the memory which eventually results in memory leaks.

The attached screenshot shows an example of this behaviour.

Thanks in advance for your help.

Best wishes,

The BTC-ES Team

Please verify that all your classes are enhanced.

The screenshot indicates using some entity objects (MappingImpl?) in reflection mode.

Reflection mode has some limitations and is generally not recommended.

Thank you very much for your hint. If we enhance all entities then it works.

Hello,

we have already again problems that the ODB file writer still holds references to entities although it is not needed.

We did following:

All entities are enhanced.

The entity DBVectorStepBlockCollectionImpl was modified and then the transaction will be committed.

em.getTransaction().commit()
em.clear()
System.gc();
em.getTransaction().begin(); // here we had a break point and did some memory profiling

See the attached screenshot.

The unnecessary references leads to memory heap space limitations.

Why the entity DBVectorStepBlockCollectionImpl is still hold by ObjectDB?

Best wishes,

The BTC-ES Team

ObjectDB keeps one delegate instance per persistable type as an optimisation for some operations. It seems that you report shows that single object. If this is the case it is only one object that was created by ObjectDB and not by your application.

We get more and more instances of com.objectdb.o.MST and com.objectdb.o.PGC which hold much memory, if we execute several transactions on the identical entity manager. Also triggering the Garbage Collector did not release the instances of MST and PGC from the heap.

Why the ObjectDB holds instances of MST and PGC after commit?

You should have one MSF/MST/PGC per open database.

Does your application use many different databases? single class loader or multiple class loaders?

Please verify that you close every EntityManager and EntityManagerFactory when not is use anymore and provide path information for the MSF/MST/PGC instances with strong references from GC roots.

We have scenarios in which we open up to lots of different Db files at the same time, each with own entitiy manager and open transaction holding a MyStepBlockCollection with read access. If all of them potentially hold this amount of memory then our application gets into trouble. So we need a solution for this serious issue.

We would like to know if

• - we do something wrong and should change the accessing methods or
• - if the analysis is right how can we make sure that memory is freed (without splitting the reading transaction into arbitrary chunks) or
• - if ObjectDB should be improved to handle this case properly

Kind regards,

Rainer Lochmann

> we open up to lots of different Db files at the same time

How many databases? Do you need all of them open at the same time?