title: Is it okay to pass injected EntityManagers to EJB bean's helper classes and use it?
body: <p>We have some JavaEE5 stateless EJB bean that passes the injected EntityManager to its helpers.  </p>
  
  <p>Is this safe? It has worked well until now, but I found out some Oracle document that states its implementation of EntityManager is thread-safe. Now I wonder whether the reason we did not have issues until now, was only because the implementation we were using happened to be thread-safe (we use Oracle).</p>
  
  <pre><code>@Stateless
  class SomeBean {
      @PersistenceContext
      private EntityManager em;
  
      private SomeHelper helper;
  
      @PostConstruct
      public void init(){
          helper = new SomeHelper(em);
      }
  
      @Override
      public void business(){
          helper.doSomethingWithEm();
      }
  
  }
  </code></pre>
  
  <p>Actually it makes sense.. If EntityManager is thread-unsafe, a container would have to do </p>
  
  <pre><code>inercept business()
  this.em = newEntityManager();
  business();
  </code></pre>
  
  <p>which will not propagate to its helper classes.  </p>
  
  <p>If so, what is the best practice in this kind of a situation? Passing EntityManagerFactory instead of EntityManager?</p>
  
  <p>EDIT: <a href="https://stackoverflow.com/questions/2015184/how-is-threadsafty-guranteed-with-persistencecontext">This question</a> is very interesting so if you are interested in this question, you probably want to check out this one, too:</p>
  
  <p>EDIT: More info.
  <a href="http://cds-esd.sun.com/ESD24/JSCDL/ejb/3.0-fr/ejb-3_0-fr-spec-ejbcore.pdf?AuthParam=1268035887_245e19638b80f7e48366ad7cff87f21c&amp;TicketId=B%2Fw7nBqJTVlDTBNCO1denQbr&amp;GroupName=CDS&amp;FilePath=/ESD24/JSCDL/ejb/3.0-fr/ejb-3_0-fr-spec-ejbcore.pdf&amp;File=ejb-3_0-fr-spec-ejbcore.pdf" rel="nofollow noreferrer">ejb3.0 spec</a></p>
  
  <blockquote>
    <p><strong>4.7.11 Non-reentrant Instances</strong> 
    The container must ensure that only one
    thread can be executing an instance at
    any time. If a client request arrives
    for an instance while the instance is
    executing another request, the
    container may throw the
    javax.ejb.ConcurrentAccessException to
    the second client[24]. If the EJB 2.1
    client view is used, the container may
    throw the java.rmi.RemoteException to
    the second request if the client is a
    remote client, or the
    javax.ejb.EJBException if the client
    is a local client.[25] Note that a
    session object is intended to support
    only a single client. Therefore, it
    would be an application error if two
    clients attempted to invoke the same
    session object. One implication of
    this rule is that an application
    cannot make loopback calls to a
    session bean instance.</p>
  </blockquote>
  
  <p>And,   </p>
  
  <blockquote>
    <p><strong>4.3.2 Dependency Injection</strong> 
    A session bean may use dependency injection
    mechanisms to acquire references to
    resources or other objects in its
    environment (see Chapter 16,
    “Enterprise Bean Environment”). If a
    session bean makes use of dependency
    injection, the container injects these
    references after the bean instance is
    created, and before any business
    methods are invoked on the bean
    instance. If a dependency on the
    SessionContext is declared, or if the
    bean class implements the optional
    SessionBean interface (see Section
    4.3.5), the SessionContext is also injected at this time. If dependency
    injection fails, the bean instance is
    discarded. Under the EJB 3.0 API, the
    bean class may acquire the
    SessionContext interface through
    dependency injection without having to
    implement the SessionBean interface.
    In this case, the Resource annotation
    (or resource-env-ref deployment
    descriptor element) is used to denote
    the bean’s dependency on the
    SessionContext. See Chapter 16,
    “Enterprise Bean Environment”.</p>
  </blockquote>