You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@airavata.apache.org by "Marcus Christie (JIRA)" <ji...@apache.org> on 2019/02/04 16:44:00 UTC
[jira] [Commented] (AIRAVATA-2961) Thread-safe getEntityManager
[ https://issues.apache.org/jira/browse/AIRAVATA-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16760011#comment-16760011 ]
Marcus Christie commented on AIRAVATA-2961:
-------------------------------------------
I changed AppCatalogJPAUtils.java and the other *JPAUtils classes to no longer have a static EntityManager field. Instead, the pattern now is
{code:java}
public class AppCatalogJPAUtils {
private static final EntityManagerFactory factory = JPAUtils.getEntityManagerFactory(PERSISTENCE_UNIT_NAME, JDBC_CONFIG);
public static EntityManager getEntityManager() {
return factory.createEntityManager();
}
}
{code}
According to the [Java EE 6 Tutorial|https://docs.oracle.com/cd/E19798-01/821-1841/bnbqy/index.html],
{quote}
... 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.*
{quote}
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: https://issues.apache.org/jira/browse/AIRAVATA-2961
> 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 commit|https://github.com/apache/airavata/commit/f51f1f16ff687768f7cfade2b92e66b84bd105d8?w=1]) 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
(v7.6.3#76005)