EJB的最佳实践:工业强度的JNDI优化 - 编程入门网
EJB的最佳实践:工业强度的JNDI优化时间:2011-02-23在这篇技巧文章中,我们将研究一些最常用的 JNDI 优化。特别地,我们将向您展示如何将高速缓存和通用助手类组合使用,以创建针对 JNDI 开销的工厂风格的解决方案。 减少上下文实例 清单 1 显示了一段典型的 EJB 代码,它需要多次 JNDI 查找。请花一点时间研究代码,然后我们将对它进行优化以获得更佳性能。 清单 1. 典型的 EJB 查找
尽管这个示例多少有点刻意,但它确实揭示了使用 JNDI 时的一些最明显的问题。对于初学者,您应该问问自己,新建 InitialContext 对象是否必需。很可能在应用程序代码的其它地方已经装入了这个上下文,而我们又在这里创建了一个新的。高速缓存 InitialContext 实例会立即促使性能提高,如清单 2 所示: 清单 2. 高速缓存 InitialContext 实例
通过对 getInitialContext() 使用助手类,而不是为每个操作都实例化一个新的 InitialContext,我们将遍布在应用程序中的上下文数量减少为一个。 线程化会怎么样? 如果您对此处提出的解决方案的线程化感到担心,那大可不必。两个线程同时进行 getInitialContext() 是绝对有可能的(从而一次创建两个上下文),但只有首次调用该方法时才会发生此类错误。因为问题至多只会发生一次,所以同步是不必要的,实际上,同步引入的复杂性比它所解决的复杂性更多。 EJB的最佳实践:工业强度的JNDI优化(2)时间:2011-02-23优化查找 高速缓存上下文实例这个步骤的方向是正确的,但仅这样做,还不足以完成优化。我们每次调用 lookup() 方法时都会执行一次新查找,并返回 bean 的 home 接口的新实例。至少,JNDI 查找通常是这样编码的。但如果每个 bean 都只有一个 home 接口,并在多个组件上共享这个接口,这样不是更好吗? 我们可以高速缓存每个单独的 bean 引用,而不是反复查找 PurchaseHome 或 InventoryHome 的 home 接口;这是一种解决方案。但我们真正想要的是一种更通用的机制:在 EJB 应用程序中高速缓存 home 接口。 答案是创建通用助手类,它既可以为应用程序中的每个 bean 获取初始上下文,又可以为它们查找 home 接口。此外,这个类还应该能够为各种应用程序组件管理每个 bean 的上下文。清单 3 中所示的通用助手类将充当 EJB home 接口的工厂: 清单 3. EJB home 接口工厂
|
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |