Note that there are some explanatory texts on larger screens.

plurals
  1. POIs it okay to pass injected EntityManagers to EJB bean's helper classes and use it?
    text
    copied!<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>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload