@EJB injection vs lookup - performance issue

Question

I have a question related with possible performance issue while using @EJB annotation. Imagine following scenario

public class MyBean1 implements MyBean1Remote{
 @EJB
 private MyBean2Remote myBean2;
 @EJB
 private MyBean2Remote myBean3;
 ...
 @EJB
 private MyBean20Remote myBean20;
}  

There is a bean with many dependencies to other beans. According to EJB spec if I would like to inject MyBean1Remote to some other bean, container would have to take all required dependencies from its pool inject it into MyBean1Remote and then inject reference to MyBean1Remote stub.

so in following scenario container needs to reserved 20 ejbs (myBean1 and its 19 dependencies)

public class MyAnotherBean implement MyAnotherRemote{
  @EJB
  private MyBean1Remote myBean1
}

Let say that in most cases we will use only single dependency per each business method of myBean1. As a result each time we want to inject that bean we force container to reserves many unnecessery EJBs. Lets also assume that we are operating on remote beans so probably container would also need to perform some load balancing algorithm prior injecting dependent beans.

Questions:

1. Wouldn't that cause unnecessary resource reservation and more over performance issue while operating in cluster environment?

2. Maybe good old ServiceLocator could be better solution because with this approach we would ask for specific EJB when we really need it ?

Answer 1

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.