我有一个与使用 @EJB 注释时可能出现的性能问题相关的问题。想象一下以下场景
public class MyBean1 implements MyBean1Remote{
@EJB
private MyBean2Remote myBean2;
@EJB
private MyBean2Remote myBean3;
...
@EJB
private MyBean20Remote myBean20;
}
有一个 bean 对其他 bean 有很多依赖关系。根据 EJB 规范,如果我想将 MyBean1Remote 注入到其他某个 bean,容器必须从其池中获取所有必需的依赖项,将其注入到 MyBean1Remote 中,然后注入对 MyBean1Remote 存根的引用。
因此在以下场景中容器需要保留 20 个 ejb(myBean1 及其 19 个依赖项)
public class MyAnotherBean implement MyAnotherRemote{
@EJB
private MyBean1Remote myBean1
}
假设在大多数情况下,我们将仅对 myBean1 的每个业务方法使用单个依赖项。因此,每次我们想要注入该 bean 时,我们都会强制容器保留许多不必要的 EJB。我们还假设我们正在远程 bean 上进行操作,因此容器可能还需要在注入依赖 bean 之前执行一些负载平衡算法。
问题:
在集群环境中运行时,这不会导致不必要的资源预留和更多的性能问题吗?
也许旧的 ServiceLocator 可能是更好的解决方案,因为通过这种方法,我们会在真正需要时请求特定的 EJB?
容器不会注入 EJB 实例;它注入一个轻量级容器生成的代理对象的实例,该对象实现所需的接口。
public class MyBean1 implements MyBean1Remote {
...
}
public class MyAnotherBean implement MyAnotherRemote {
@EJB
private MyBean1Remote myBean1;
}
在您的示例中,MyAnotherBean.myBean1 将注入一个实现 MyBean1Remote 接口的代理对象。
假设一个无国籍的会话 bean(因为您提到了池化),容器不会从方法就绪池中分配实际的 EJB 实例,直到在代理上调用方法为止,并且在代理方法调用返回之前将该实例返回到池中。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)