Hello Jason,
Although I am not familiar with your specific requirements If you
are running in a EE compliant server you may want to simply inject the
EntityManager into the SessionBean directly without accessing the EMF
and managing the EntityManager directly. It really has no impact on the
statefulness of the SessionBean. What you may want to determine is
whether an Extended Persistence Context should be used in the case of
the Stateful Sessionbeans. An Extended Persistence Context should have
the same lifecycle as the Stateful SessionBean.
There should be no problems deleting an instance of a Entity from
another EntityManager within the current EntityManager.
--Gordon
Jason Lee wrote:
> Since we migrated our environment to a full Java EE stack (versus the
> JSF on Tomcat environment we were using), we've been injecting an
> EntityManagerFactory into our JSF managed beans, on the advice the
> EntityManager is not thread-safe. We have started, however, to use
> more and Session Beans (stateful and stateless) to deploy our service
> (and DAO) layers, as we've had the need to expose some of the business
> logic in an app to external process, for example. Our "stack" then,
> is now basically JSF managed bean/backing bean -> State{ful|ess}
> Session Bean service layer -> State{ful|less} DAO layer, which, this
> morning, brought up these questions:
>
> * Do we still need to inject an EMF into our DAO EJB?
> * Does that depend on the statefulness of the bean?
> * Is there a best practice with regard to the statefulness of a DAO
> Session Bean?
>
> I ran into some issues in handling an entity bean fetched from on EM
> instance and trying to remove it with another EM instance, so I'm
> wondering if I can simplify things a bit by injecting an EM (or
> creating the EM from the EMF in a @PostConstruct), or if I just need
> to make the API calls to reattach the instance.
>
> -----
> Jason Lee, SCJP
> Programmer/Analyst
> http://www.iec-okc.com <http://www.iec-okc.com/>
>