I have a question related with possible performance issue while using @EJB annotation. Imagine following scenario
public class MyBean1 implements MyBean1Remo
The container does not inject an instance of the EJB; it injects an instance of a lightweight container-generated proxy object that implements the desired interface.
public class MyBean1 implements MyBean1Remote {
...
}
public class MyAnotherBean implement MyAnotherRemote {
@EJB
private MyBean1Remote myBean1;
}
In your example, MyAnotherBean.myBean1 will be injected with a proxy object that implements the MyBean1Remote interface.
Assuming a stateless session bean (since you mention pooling), the container does not allocate an actual EJB instance from the method-ready pool until a method is called on the proxy, and the instance is returned to the pool before the proxy method call returns.
In most cases and especially when using stateless session beans, your bean instances will be pooled. One of the rationales behind pooling is that dependency injection lookups might be relatively expensive, so the bean is pooled with (stubs for) all its dependencies already injected.
So every time you call a method on MyAnotherBean
, This bean with its 20 transitive dependencies isn't created with all those dependencies resolved on the fly. Instead, a fully instantiated instance is selected from the pool and the method call is directed to that.
Also note that unless you are doing JNDI federation you normally can't easily inject remote EJBs.