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 {