连接池：深入 J2EE 的连接合用

核心提示： EJB 层的设计考虑事项尽管有了管理连接池的资源管理器，但是还不能保证 EJB 层具有最优性能 -- 还有一些设计考虑事项！首先，连接池：深入 J2EE 的连接合用(6)，考虑以下 EJB 客户机代码示例，该客户机访问实现连接池的 LDAP 目录 ，从而使 EJB 层从处理特定于供应商的库中解脱

EJB 层的设计考虑事项

尽管有了管理连接池的资源管理器，但是还不能保证 EJB 层具有最优性能 -- 还有一些设计考虑事项！

首先，考虑以下 EJB 客户机代码示例，该客户机访问实现连接池的 LDAP 目录 。

import　netscape.ldap.util.*;　
...　
public　class　NewCustomerBean　implements　SessionBean　{　
...　
private　SessionContext　context;　//　Bean　Context　
private　LDAPConnection　lc;　//　LDAP　Connection　object　
...　
public　void　setSessionContext(SessionContext　sc)　{　
this.context　=　sc;　
//　initialize　JNDI　lookup　parameters　
Context　ctx　=　new　InitialContext(parms);　
...　
ConnectionPool　cp　=　(ConnectionPool)ctx.lookup(cpsource);　
//　Establish　LDAP　Connection.　
try　{　
this.lc　=　cp.getConnection();　
...　
}　

以上做法有什么不妥吗？首先，有状态会话对象 ( NewCustomerBean ) 在 setEntityContext 中打开连接对象，然后持续占用它，直到使用完为止 -- 如果用户（会话）数量迅速增加，就成为代价相当大的实现。第二，也是更重要的，因为连接对象不是序列化的，所以，按照 EJB 1.2 规范，容器可以在钝化时（例如，将会话 bean 从其活动状态移至 bean 实例池）废弃 bean 实例。

一种替代方法是分别在会话 bean 的 ejbActivate() 和 ejbPassivate() 方法中获取和释放资源连接。如果没有连接池，代价当然会很高，也不会建议那样做。然而，有了合用之后，使用该技术，可以用最小的 EJB 层开销来获取和释放连接。这里的要点在于：除了规范和实现所提供的设施之外，设计选择总是关键性能决定因素。

第二个考虑事项是有关认证问题的。您可能已经注意到，合用的连接意味着共享的连接，而共享的连接意味着连接不与特定的认证证书绑定。例如，在 JDBC 2.0 连接中，应用服务器池管理器在启动时，使用一个存储在配置文件中的认证证书（通常是用户标识／口令）来从数据库管理器请求预设数量的连接。有时候，那可能不满足应用的安全性策略。LDAP 连接需要将 LDAP 子树与特定证书绑定，因而也有同样的问题。在那些情况下，一种替代方法可能是使用利用特定证书建立好的已高速缓存的连接，它可以对相同类型的证书重复使用。这种方法的不利之处是已高速缓存的连接要保留很长时间。另一种替代方法可能是对资源使用通用连接，并实现某种应用层安全性。

结束语

在本文中，我根据资源的共享特性和访问资源的 EJB 组件，显示了 J2EE 环境中连接合用资源的必要。您已看到由 JDBC 2.0、JMS 1.02 和 JNDI 1.2 标准扩展 API 定义的设施，和供应商对那些 API 接口实现的支持。虽然特定于供应商的解决方案很健壮，但是对它们的使用却是以 EJB 的可移植性作为代价的。即将出现的 J2EE Connector Architecture 1.0 解决了该问题，并使资源可插入，从而使 EJB 层从处理特定于供应商的库中解脱出来。最后，我解释了为什么您的设计在利用那些合用技术来制作高性能的 J2EE 应用方面扮演着重要角色。