@EJB注入vs查找-性能问题 [英] @EJB injection vs lookup - performance issue

问题描述

在使用@EJB注释时，我有一个与可能的性能问题有关的问题.想象以下情况

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;
}  

有一个与其他bean有很多依赖性的bean.根据EJB规范，如果我想将MyBean1Remote注入其他某个bean，容器将必须从其池中获取所有必需的依赖项，然后将其注入MyBean1Remote，然后注入对MyBean1Remote存根的引用.

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.

因此在以下情况下，容器需要保留20个ejb(myBean1及其19个依赖项)

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

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

让我们说，在大多数情况下，我们每个myBean1业务方法仅使用单个依赖项.结果，每次我们要注入该bean时，我们都会强制容器保留许多不必要的EJB.我们还假设我们在远程bean上进行操作，因此容器在注入依赖的bean之前可能还需要执行一些负载平衡算法.

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.

问题:

1. 在集群环境中运行时，这是否会导致不必要的资源保留以及更多的性能问题?

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

也许好的旧ServiceLocator可能是更好的解决方案，因为使用这种方法，我们会在真正需要它时请求特定的EJB?

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

推荐答案

容器未注入EJB的实例；它注入了一个轻量级容器生成的代理对象的实例，该实例实现了所需的接口.

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;
}

在您的示例中，将向MyAnotherBean.myBean1注入一个实现MyBean1Remote接口的代理对象.

In your example, MyAnotherBean.myBean1 will be injected with a proxy object that implements the MyBean1Remote interface.

假设无状态会话Bean(因为您提到了池)，容器直到在代理上调用方法之前，该容器才从方法就绪的池中分配实际的EJB实例.在代理方法调用返回之前返回到池中.

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.

这篇关于@EJB注入vs查找-性能问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！