[hibernate-issues] [Hibernate-JIRA] Updated: (EJB-219) Add an EntityManagerFactory.getCurrentEntityManager() method.

[James Olsen (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-219?page=all ]

James Olsen updated EJB-219:
----------------------------

    Attachment: JTAScopedEMPatch.txt

Here's an untested patch that shows how I think this might be done.  Would appreciate any pointers you can give.  Will start testing it soon.

> Add an EntityManagerFactory.getCurrentEntityManager() method.
> -------------------------------------------------------------
>
>          Key: EJB-219
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-219
>      Project: Hibernate Entity Manager
>         Type: New Feature

>   Components: EntityManager
>  Environment: Hibernate 3.2. Any/All.
>     Reporter: James Olsen
>  Attachments: JTAScopedEMPatch.txt
>
>
> BACKGROUND
> I'd like to code against the JPA standard, however my current EJB container vendor (like many others) is only providing JPA support as part of their EJB3 rollout which is at a very early stage.
> JPA doesn't need a full EJB3 environment.  The only required apsect that appears to be missing in existing EJB containers is container management and injection of a correctly scoped EntityManager.  I can deal with the injection problem by having a Singleton accessor for the EntityManagerFactory in much the same way as the well known HibernateUtil deals with the SessionFactory.  All that is left then is providing something similar to the automatic JTA/CMT context scoping of Sessions for EntityManager instances.
> SUGGESTION
> I would propose that a new custom API be added to org.hibernate.ejb.EntityManagerFactoryImpl in the form of a method called getCurrentEntityManager().  Internally this would construct an EntityManagerImpl that was configured to do sessionFactory.getCurrentSession() rather than sessionFactory.openSession() (inside the getRawSession() method), thereby leveraging Hibernates pre-existing capability to return correctly scoped units of work in a JTA/CMT environment.  Thats sounds easy, but maybe there's more to it!?
> JUSTIFICATION
> The advantage of having such an API is that we can write to the JPA API without waiting for full EJB3 support in the container.  The little bit of application code to obtain the EntityManagerFactory, cast to the Hibernate impl and call this custom method can easily be removed in the future when EntityManager injection is available.
> I've looked at using Spring and Pitchfork but  as great as they are, they are heavy handed when you already have a container and my customer demands a container and also has an aversion to non GA code (implies I'm confident the Hibernate 3.2 products will be GA soon - which I am!).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira