Инъекция @EJB против поиска - проблема с производительностью

У меня вопрос, связанный с возможной проблемой производительности при использовании аннотации @EJB. Представьте себе следующий сценарий

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

. Существует компонент со многими зависимостями от других компонентов. Согласно спецификации EJB, если я хочу внедрить MyBean1Remote в какой-либо другой компонент, контейнер должен был бы взять все необходимые зависимости из своего пула, ввести его в MyBean1Remote, а затем вставить ссылку на заглушку MyBean1Remote.

поэтому в следующем сценарии контейнер должен зарезервировать 20 ejbs (myBean1 и его 19 зависимостей)

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

Допустим, что в в большинстве случаев мы будем использовать только одну зависимость для каждого бизнес-метода myBean1. В результате каждый раз, когда мы хотим внедрить этот компонент, мы заставляем контейнер резервировать множество ненужных EJB. Предположим также, что мы работаем с удаленными bean-компонентами, поэтому, вероятно, контейнеру также потребуется выполнить некоторый алгоритм балансировки нагрузки перед внедрением зависимых bean-компонентов.

Вопросы:

1. Не будет t, которые вызывают ненужное резервирование ресурсов и, более того, проблемы с производительностью при работе в кластерной среде?

2. Может быть, старый добрый ServiceLocator мог бы быть лучшим решением, потому что при таком подходе мы будем запрашивать конкретный EJB, когда он нам действительно нужен?