airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Christie (JIRA)" <>
Subject [jira] [Commented] (AIRAVATA-2961) Thread-safe getEntityManager
Date Mon, 04 Feb 2019 16:44:00 GMT


Marcus Christie commented on AIRAVATA-2961:

I changed and the other *JPAUtils classes to no longer have a static
EntityManager field. Instead, the pattern now is
public class AppCatalogJPAUtils {
    private static final EntityManagerFactory factory = JPAUtils.getEntityManagerFactory(PERSISTENCE_UNIT_NAME,

    public static EntityManager getEntityManager() {
        return factory.createEntityManager();

According to the [Java EE 6 Tutorial|],

... The EntityManager and its associated persistence context are created and destroyed explicitly
by the application. They are also used when directly injecting EntityManager instances can’t
be done because *EntityManager instances are not thread-safe. EntityManagerFactory instances
are thread-safe.*

So it should be safe to statically create a thread-safe EntityManagerFactory. In the previous
code there was a static EntityManager field that I believe was the source of the thread-safety
issues. Eliminating that field and always simply returning the EntityManager should resolve
the thread-safety issues.

On the other hand, it might make sense to not create the EntityManagerFactory via a static
initializer when the class is loaded. A singleton pattern would allow better control over
when the EntityManagerFactory is created. For example, if the EntityManagerFactory is created
early, before the DBInitializer runs to create the database tables, the mappings validation
will fail (in practice this doesn't happen, but a small code re-organization could lead to
this sort of thing happening).

> Thread-safe getEntityManager
> ----------------------------
>                 Key: AIRAVATA-2961
>                 URL:
>             Project: Airavata
>          Issue Type: Bug
>            Reporter: Marcus Christie
>            Priority: Major
> Something similar to what was done for the app catalog in the old registry (see [this
should be done for the new registry EntityManager utilities.
> I'm also wondering if we really need to evict the cache. Since gfac is calling the registry
through the CPI this shouldn't be needed. Or we should just disable second level cache.

This message was sent by Atlassian JIRA

View raw message