EJB 最佳实践：工业强度的 JNDI 优化 |
| 时间：2014-05-04 10:33:52 来源：JSP天空网 作者：未知 |
使用高速缓存和通用工厂类使 JNDI 查找自动化
级别：中级
Brett McLaughlin（brett@oreilly.com）
作家兼编辑，O´Reilly and Associates
2002 年 11 月
Brett McLaughlin 在这篇 EJB 最佳实践专栏文章中研究了 JNDI 查找，它是几乎所有的 EJB 交互中不可或缺并且常见的部分。遗憾的是，JNDI 操作几乎总是需要性能开销。在本技巧文章中，Brett 向您展示了 home 接口工厂是如何降低您 EJB 应用程序中 JNDI 查找开销的。
每种 EJB 组件（会话、实体和消息驱动的）都有 home 接口。home 接口是 bean 的操作基础；一旦您找到它，就可以使用该 bean 的功能。EJB 应用程序依靠 JNDI 查找来访问其 bean 的 home 接口。因为 EJB 应用程序往往运行多个 bean，并且因为许多组件中经常使用 JNDI 查找，所以应用程序大部分性能开销都花费在这些查找上。
在这篇技巧文章中，我们将研究一些最常用的 JNDI 优化。特别地，我们将向您展示如何将高速缓存和通用助手类组合使用，以创建针对 JNDI 开销的工厂风格的解决方案。
减少上下文实例
清单 1 显示了一段典型的 EJB 代码，它需要多次 JNDI 查找。请花一点时间研究代码，然后我们将对它进行优化以获得更佳性能。
清单 1. 典型的 EJB 查找
public boolean buyItems(PaymentInfo paymentInfo, String storeName,
List items) {
// Load up the initial context
Context ctx = new InitialContext();
// Look up a bean´s home interface
Object obj = ctx.lookup("java:comp/env/ejb/PurchaseHome");
PurchaseHome purchaseHome =
(PurchaseHome)PortableRemoteObject.narrow(obj, PurchaseHome.class);
Purchase purchase = purchaseHome.create(paymentInfo);
// Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); ) {
purchase.addItem((Item)i.next());
}
// Look up another bean
Object obj = ctx.lookup("java:comp/env/ejb/InventoryHome");
InventoryHome inventoryHome =
(InventoryHome)PortableRemoteObject.narrow(obj, InventoryHome.class);
Inventory inventory = inventoryHome.findByStoreName(storeName);
// Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); )
inventory.markAsSold((Item)i.next());
}
// Do some other stuff
}
尽管这个示例多少有点刻意，但它确实揭示了使用 JNDI 时的一些最明显的问题。对于初学者，您应该问问自己，新建 InitialContext 对象是否必需。很可能在应用程序代码的其它地方已经装入了这个上下文，而我们又在这里创建了一个新的。高速缓存 InitialContext 实例会立即促使性能提高，如清单 2 所示：
清单 2. 高速缓存 InitialContext 实例
public static Context getInitialContext() {
if (initialContext == null) {
initialContext = new InitialContext();
}
return initialContext;
}
通过对 getInitialContext() 使用助手类，而不是为每个操作都实例化一个新的 InitialContext，我们将遍布在应用程序中的上下文数量减少为一个。
哦 ? 线程化会怎么样？
如果您对此处提出的解决方案的线程化感到担心，那大可不必。两个线程同时进行 getInitialContext() 是绝对有可能的（从而一次创建两个上下文），但只有首次调用该方法时才会发生此类错误。因为问题至多只会发生一次，所以同步是不必要的，实际上，同步引入的复杂性比它所解决的复杂性更多。
优化查找
高速缓存上下文实例这个步骤的方向是正确的，但仅这样做，还不足以完成优化。我们每次调用 lookup() 方法时都会执行一次新查找，并返回 bean 的 home 接口的新实例。至少，JNDI 查找通常是这样编码的。但如果每个 bean 都只有一个 home 接口，并在多个组件上共享这个接口，这样不是更好吗？
我们可以高速缓存每个单独的 bean 引用，而不是反复查找 PurchaseHome 或 InventoryHome 的 home 接口；这是一种解决方案。但我们真正想要的是一种更通用的机制：在 EJB 应用程序中高速缓存 home 接口。
答案是创建通用助手类，它既可以为应用程序中的每个 bean 获取初始上下文，又可以为它们查找 home 接口。此外，这个类还应该能够为各种应用程序组件管理每个 bean 的上下文。清单 3 中所示的通用助手类将充当 EJB home 接口的工厂：
清单 3. EJB home 接口工厂
package com.ibm.ejb;
import java.util.Map;
import javax.ejb.EJBHome;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
public class EJBHomeFactory {
private static EJBHomeFactory;
private Map homeInterfaces;
private Context context;
// This is private, and can´t be instantiated directly
private EJBHomeFactory() throws NamingException {
homeInterfaces = new HashMap();
// Get the context for caching purposes
context = new InitialContext();
/**
* In non-J2EE applications, you might need to load up
* a properties file and get this context manually. I´ve
* kept this simple for demonstration purposes.
*/
}
public static EJBHomeFactory getInstance() throws NamingException {
// Not completely thread-safe, but good enough
// (see note in article)
if (instance == null) {
instance = new EJBHomeFactory();
}
return instance;
}
public EJBHome lookup(String jndiName, Class homeInterfaceClass)
throws NamingException {
// See if we already have this interface cached
EJBHome homeInterface = (EJBHome)homeInterfaces.get(homeClass);
// If not, look up with the supplied JNDI name
if (homeInterface == null) {
Object obj = context.lookup(jndiName);
homeInterface =
(EJBHome)PortableRemoteObject.narrow(obj, homeInterfaceClass);
// If this is a new ref, save for caching purposes
homeInterfaces.put(homeInterfaceClass, homeInterface);
}
return homeInterface;
}
}
EJBHomeFactory 类内幕
home 接口工厂的关键在 homeInterfaces 映射中。该映射存储了供使用的每个 bean 的 home 接口；这样，home 接口实例可以反复使用。您还应注意，映射中的关键并不是传递到 lookup() 方法的 JNDI 名称。将同一 home 接口绑定到不同 JNDI 名称是很常见的，但这样做会在您的映射中产生副本。通过依靠类本身，您就可以确保最终不会为同一个 bean 创建多个 home 接口。
将新的 home 接口工厂类插入清单 1 的原始代码，这样将会产生优化的 EJB 查找，如清单 4 所示：
清单 4. 改进的 EJB 查找
public boolean buyItems(PaymentInfo paymentInfo, String storeName,
List items) {
EJBHomeFactory f = EJBHomeFactory.getInstance();
PurchaseHome purchaseHome =
(PurchaseHome)f.lookup("java:comp/env/ejb/PurchaseHome",
PurchaseHome.class);
Purchase purchase = purchaseHome.create(paymentInfo);
// Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); ) {
purchase.addItem((Item)i.next());
}
InventoryHome inventoryHome =
(InventoryHome)f.lookup("java:comp/env/ejb/InventoryHome",
InventoryHome.class);
Inventory inventory = inventoryHome.findByStoreName(storeName);
// Work on the bean
for (Iterator i = items.iterator(); i.hasNext(); ) {
inventory.markAsSold((Item)i.next());
}
// Do some other stuff
}
随着时间的推进，除了更清晰之外（至少按我的观点），以上工厂优化的 EJB 查找将执行得更快。您第一次使用这个新类时，将花费所有正常查找开销（假定应用程序的其它部分没有付出过这种开销），但将来的所有 JNDI 查找都将继续使用原先的查找结果。还有必要指出，home 接口工厂不会干扰您容器的bean 管理。容器管理的是 bean 实例，而不是这些 bean 实例的 home 接口。您的容器还将管理实例交换，以及其它您希望它执行的任何优化。
在 EJB 最佳实践的下一篇文章中，我将向您展示如何启用对实体 bean的管理访问，而又不必将它们直接暴露给您应用程序的 Web 层。到那时，我们网上见。
参考资料
Sun Microsystems 的 EJB 技术主页是所有与 EJB 技术相关内容的良好参考资料。
TheServerSide 提供了许多有关 J2EE 的文章和信息。
jGuru EJB fundamentals 教程（developerWorks，2001 年 3 月）提供了 Enterprise JavaBeans 技术的全面介绍，并特别关注了 EJB 组件在分布式计算案例中的作用、体系架构、扩展 API，以及使用 EJB 技术的基础。
访问 developerWorks Java 教程页面以获取其它免费的 EJB 和 J2EE 相关教程列表。
在 developerWorks Java 技术专区您可以找到数百篇有关 Java 编程各个方面的文章。
关于作者
Brett McLaughlin 从 Logo 时代（还记得那个小三角形么？）就开始从事计算机工作了。他现在专门研究用 Java 和 Java 相关技术构建应用程序基础结构。过去几年他一直在 Nextel Communications 和 Allegiance Telecom, Inc. 致力于实现这些基础结构。Brett是 Java Apache 项目 Turbine 的共同创始人之一，该项目用 Java servlet 为 Web 应用程序开发构建可重用的组件体系架构。他还是 EJBoss 项目（一个开放源码的 EJB 应用程序服务器）和 Cocoon（一个开放源码的 XML Web 发布引擎）的参与者之一。 |
|
|
|
