通过服务器端所有三层中的组件实现一个典型的电子商务应用用例。考虑到用户交互数量的庞大(对于面对客户的应用,有上百万个),需要优化地共享有限的服务器端资源。这类资源可能包括数据库、消息队列、目录、企业系统 (SAP、CICS) 等等,它们中的每一个都可以由使用代表资源访问点的连接对象的应用来访问。管理对那些共享资源的访问对于满足 J2EE 应用的高性能需求来说至关重要。
连接合用是由数据库供应商倡导的技术,其目的是允许客户机共享一组高速缓存的连接对象,这些对象提供对数据库资源的访问。在本文中,我分析了 J2EE 环境中服务器端资源(例如数据库、消息队列、目录和企业系统)的连接合用。
· 为何合用资源连接?
考虑一下 代码示例 ,其中,EJB 使用 JDBC 1.0、 不使用 连接合用来访问数据库资源。
很明显,该示例的主要问题是连接的打开和关闭。考虑到实体 bean 是共享组件,因此,对每个客户机请求,都要进行几次获取和释放数据库连接的操作。
从图 1 可以看出,使用 JDBC 1.0 通过数据库管理器获取和释放数据库连接将影响 EJB 层的性能。这种影响是由数据库资源管理器进程创建和摧毁那些对象而引起的。应用服务器一般需要花 1 到 3 秒的时间来建立数据库连接(包括与服务器通信、认证等等),并需要对每一个客户机 (EJB) 的请求进行连接。
图 1. 使用 JDBC 1.0 的连接管理
使用服务供应商设施的连接合用
现在看一下在 J2EE 环境中,数据库和非数据库资源类型当前可以使用哪些连接合用设施。
JDBC 2.0 标准扩展 API
JDBC 2.0 标准扩展 API 指定数据库服务供应商可以实现具有以下特性的合用技术:允许请求客户机透明地共享资源池的多个连接对象。在那种情况下,因为池管理器预先在启动时创建连接对象,所以,J2EE 组件可以使用连接对象,而不会导致数据库资源管理器上的系统开销。应用服务器供应商在其内存空间实现池管理器,并根据需要动态改变池的大小,从而优化资源的使用。图 2 中显示了这种情况。
图 2. 使用 JDBC 2.0 标准扩展的连接合用
通过使用 DataSource 接口 (JDBC 2.0) 或 DriverManager (JDBC 1.0) 接口,J2EE 组件可以获得物理数据库连接对象。要获得逻辑(合用的)连接,J2EE 组件必须使用以下这些 JDBC 2.0 合用管理器接口:
对于那些接口和 XA 连接的每一个,都存在一个 XA(X/Open 规范)等价定义。
以下代码示例显示了 EJB 应用如何利用合用的连接对象来访问数据库资源(基于 JDBC 2.0)。本例中的 EJB 组件使用 JNDI 查询来确定数据库连接池资源的位置。JNDI 1.2 标准扩展 API 允许 Java 应用以相同的方式访问位于完全不同的目录和命名系统中的对象。使用 JNDI API,应用可以查询目录来确定任何资源(例如,数据库服务器、LDAP 服务器、打印服务器、消息服务器、文件服务器等等)的位置。有关 JNDI 的合适概述,请参阅 "The Java Naming and Directory Interface (JNDI): A More Open and Flexible Model" 。
请注意: 实际代码 可能会根据数据库供应商实现类的不同而不同。
以上代码(使用 JDBC 2.0)和使用 JDBC 1.0 的主要不同在于: getConnection() 从池中获取已打开的连接,而 close() 只将连接对象释放回池。如今,几乎每一家数据库服务器供应商(如 Oracle、DB2、Sybase 和 Informix)都提供 JDBC 2.0 驱动程序。如今大多数应用服务器供应商(IBM、BEA、iPlanet、IONA 等)也都支持 JDBC 2.0。
应该说明的一点是:如今,几乎所有应用服务器都采用两层连接合用体系结构,其中,池位于应用服务器内存空间(与独立的连接代理不同)。
(未完待续)