通過服務器端所有三層中的組件實現一個典型的電子商務應用用例??紤]到用戶交互數量的龐大(對于面對客戶的應用,有上百萬個),需要優化地共享有限的服務器端資源。這類資源可能包括數據庫、消息隊列、目錄、企業系統 (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。
應該說明的一點是:如今,幾乎所有應用服務器都采用兩層連接合用體系結構,其中,池位于應用服務器內存空間(與獨立的連接代理不同)。
(未完待續)
原文轉自:http://www.anti-gravitydesign.com