You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Rohit Dilip Kelapure (JIRA)" <ji...@apache.org> on 2010/10/05 19:35:32 UTC

[jira] Created: (OPENJPA-1824) OpenBooks should used container managed persistence when deployed in an application server.

OpenBooks should used container managed persistence when deployed in an application server.
-------------------------------------------------------------------------------------------

                 Key: OPENJPA-1824
                 URL: https://issues.apache.org/jira/browse/OPENJPA-1824
             Project: OpenJPA
          Issue Type: Bug
          Components: samples
    Affects Versions: 2.0.1
         Environment: Windows Sever 2003
            Reporter: Rohit Dilip Kelapure
            Priority: Minor


OpenBooks is using an app managed persistence context and it isn't cleaning up properly. openbook.server.ServiceFactory.getService(...) creates an EMF, but it is never closed.
OpenBooks application is using an app managed persistence context which is NOT cleaned up correctly when deployed in a JEE server.
This results in the JEE container JPA Runtime does NOT calling DataCacheManager.close() on the DataCacheManager plugin.

The container JPA Runtime does NOT call openjpa.DataCacheManager.close() when the application is stopped.
This does not give a chance to any OpenJPA L2 cache provider to cleanup their resources and remove cache instances from static hashmaps. utlimately resulting in a memory leak.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (OPENJPA-1824) OpenBooks should used container managed persistence when deployed in an application server.

Posted by "Rohit Dilip Kelapure (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rohit Dilip Kelapure updated OPENJPA-1824:
------------------------------------------


The way OpenBooks build dependencies are setup, one cannot inject an emf/PersistenceContext without modifying the pom.xml to pull in JEE apis. Therefore submitting a patch for this issue is difficult as it necessitates making changes to the build. 

Ideally I would like to make ServiceFactory a stateless EJB and Inject a PersistenceContext in a server JEE environment so that one could get a server manged emf rather than creating one explicitly through Persistence.createEntityManagerFactory...

>From Pinaki Poddar .....
the PersistenceService should more be like a delegation than an inheritence 
-then you can create a 'business service' and inject a EMF into it easier 
-whether that EMF itself is injected by a JEE container or hand-constructed in JSE 
-will be orthogonal to the 'business service' 
-that just needs a EMF and somehow expects a session-per-thread model 

--- OpenBooks design constraint is that a business serivice must compile without JEE libs --- 


> OpenBooks should used container managed persistence when deployed in an application server.
> -------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1824
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1824
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: samples
>    Affects Versions: 2.0.1
>         Environment: Windows Sever 2003
>            Reporter: Rohit Dilip Kelapure
>            Priority: Minor
>
> OpenBooks is using an app managed persistence context and it isn't cleaning up properly. openbook.server.ServiceFactory.getService(...) creates an EMF, but it is never closed.
> OpenBooks application is using an app managed persistence context which is NOT cleaned up correctly when deployed in a JEE server.
> This results in the JEE container JPA Runtime does NOT calling DataCacheManager.close() on the DataCacheManager plugin.
> The container JPA Runtime does NOT call openjpa.DataCacheManager.close() when the application is stopped.
> This does not give a chance to any OpenJPA L2 cache provider to cleanup their resources and remove cache instances from static hashmaps. utlimately resulting in a memory leak.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (OPENJPA-1824) OpenBooks should used container managed persistence when deployed in an application server.

Posted by "Rohit Dilip Kelapure (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rohit Dilip Kelapure updated OPENJPA-1824:
------------------------------------------


CMVC Defect# 668904

> OpenBooks should used container managed persistence when deployed in an application server.
> -------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1824
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1824
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: samples
>    Affects Versions: 2.0.1
>         Environment: Windows Sever 2003
>            Reporter: Rohit Dilip Kelapure
>            Priority: Minor
>
> OpenBooks is using an app managed persistence context and it isn't cleaning up properly. openbook.server.ServiceFactory.getService(...) creates an EMF, but it is never closed.
> OpenBooks application is using an app managed persistence context which is NOT cleaned up correctly when deployed in a JEE server.
> This results in the JEE container JPA Runtime does NOT calling DataCacheManager.close() on the DataCacheManager plugin.
> The container JPA Runtime does NOT call openjpa.DataCacheManager.close() when the application is stopped.
> This does not give a chance to any OpenJPA L2 cache provider to cleanup their resources and remove cache instances from static hashmaps. utlimately resulting in a memory leak.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (OPENJPA-1824) OpenBooks should used container managed persistence when deployed in an application server.

Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Sutter updated OPENJPA-1824:
----------------------------------

    Comment: was deleted

(was: CMVC Defect# 668904)

> OpenBooks should used container managed persistence when deployed in an application server.
> -------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1824
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1824
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: samples
>    Affects Versions: 2.0.1
>         Environment: Windows Sever 2003
>            Reporter: Rohit Dilip Kelapure
>            Priority: Minor
>
> OpenBooks is using an app managed persistence context and it isn't cleaning up properly. openbook.server.ServiceFactory.getService(...) creates an EMF, but it is never closed.
> OpenBooks application is using an app managed persistence context which is NOT cleaned up correctly when deployed in a JEE server.
> This results in the JEE container JPA Runtime does NOT calling DataCacheManager.close() on the DataCacheManager plugin.
> The container JPA Runtime does NOT call openjpa.DataCacheManager.close() when the application is stopped.
> This does not give a chance to any OpenJPA L2 cache provider to cleanup their resources and remove cache instances from static hashmaps. utlimately resulting in a memory leak.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (OPENJPA-1824) OpenBooks should used container managed persistence when deployed in an application server.

Posted by "Jeremy Bauer (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OPENJPA-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923506#action_12923506 ] 

Jeremy Bauer commented on OPENJPA-1824:
---------------------------------------

I think introducing an EJB into the sample would limit its use to only JEE environments with an EJB container.  Since all you really need is a way to inject an emf, you might be able to accomplish that by introducing a dispatcher servlet or a listener into the app.  That would only require inclusion of the Geronimo servlet API into the build, instead of the EJB and potentially other libraries.

> OpenBooks should used container managed persistence when deployed in an application server.
> -------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-1824
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-1824
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: samples
>    Affects Versions: 2.0.1
>         Environment: Windows Sever 2003
>            Reporter: Rohit Dilip Kelapure
>            Priority: Minor
>
> OpenBooks is using an app managed persistence context and it isn't cleaning up properly. openbook.server.ServiceFactory.getService(...) creates an EMF, but it is never closed.
> OpenBooks application is using an app managed persistence context which is NOT cleaned up correctly when deployed in a JEE server.
> This results in the JEE container JPA Runtime does NOT calling DataCacheManager.close() on the DataCacheManager plugin.
> The container JPA Runtime does NOT call openjpa.DataCacheManager.close() when the application is stopped.
> This does not give a chance to any OpenJPA L2 cache provider to cleanup their resources and remove cache instances from static hashmaps. utlimately resulting in a memory leak.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.