Fast Object Database for Java - with JPA/JDO support

Pooling of EntityManagers


Hello Support-Team

This is more a question then a feature request, so sorry for the topic (because it's definitly no bug)

In our serverapplication the entity-managers are wrapped around a persistence-manager. We start to make them stateless and to increase performance the persistence-managers (who capsulated the entity-managers) should be part of a pooling (reusing).

Because creating an entity-manager seams to be cheap one idea is to close the entity-manager while returning the persistence-manager. While activating a persistence-manager a new entity-manager should be created.

Another idea ist to clear the entity-manager and leave it attachted for further using. Are there any concerns against this idea? Or maybe is there an internal pooling in objectdb which makes this idea useless? Is there any upper-limit of attached but not used entity-managers wich might impact the over-all performance?

sorry for bothering you

best regards



As it is usually the case with optimizations, it is impossible to predict the exact effect and the best way is to try both options (in production) and then choose the better one.

The two options are not identical. ObjectDB uses an internal pool of connections, and when an EntityManager is closed the underlying socket to the server is returned to the pool and can be reused with another new EntityManager, as this is the most expensive resource. However, the persistence context, i.e., the first level cache that an EntityManager holds is not preserved or reused. Is may be worth reusing these caches as well in some cases (when possible, i.e., if there is no conflict due to other threads still using objects from the persistence context). However, whether it improves performance or not depends on too many factors, and therefore, should be checked per application.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

thanks for quick report.

Of course I will compare both approaches in the end. Unfortunatly I'm still confused in relation to first level cache and the described conflict if other entity managers use the same objects at the same time. If I call


does the first level cache is empty then? If not does fetching an object, wich meanwhile is changed in the database by another entity-manager will be reloadet or does the cleared entity-manager will use the cached but outdated version? Just for information, we are using the entity-managers in embeddet mode.

best regards



If you call clear then you empty the persistence context / first level cache. However, possibly the main gain from pooling EntityManager instances is to keep that cache live (in case it improves performance, which has to be checked in your specific case).

Each EntityManager has its own persistence context. This allows working on the same database object in different threads, where the same database object is represented by different memory objects in different EntityManager instances. The possible issue with the proposed pool is if the old thread is still holding managed objects from the EntityManager, and the new thread that got the ownership on that EntityManager is working on the same memory objects.

ObjectDB Support
ObjectDB - Fast Object Database for Java (JPA/JDO)

Now it's clear to me. I want to avoid managed objects in the pooled entitymanager (which means not to reuse first level cache) because it's likely that they might be changed from different threads or sessions. So I assume that there will be no much difference between creating a new entitymanager and reusing an empty one. However, i will test it.

thanks again


Post Reply