深入 J2EE 連接池技術：從 JDBC 2.0 到 Connector Architecture 的演進與實踐

前言：為何需要連接池？

J2EE 應用面對龐大用戶請求，頻繁建立/關閉資料庫連接會造成嚴重效能瓶頸。建立一個資料庫連接通常需 1-3 秒（網路通訊、認證、資源分配），若每請求建立一次，系統吞吐量將極低。連接池技術預先建立連接物件並快取重用，將獲取/釋放連接降為微秒級操作。

無連接池的代價 (JDBC 1.0)

// 每次請求都建立新連接
Connection conn = DriverManager.getConnection(url, user, pass);
try { /* 業務邏輯 */ } finally { conn.close(); } // 真正關閉物理連接

EJB 容器頻繁向 DB 管理程序申請/銷毀連接，系統開銷極大。

JDBC 2.0 標準擴展：標準化連接池

JDBC 2.0 引入 javax.sql 套件，定義標準連接池介面，資料庫廠商提供實作：

EJB 使用池化連接範例

// JNDI 查詢 DataSource (由應用伺服器配置管理連接池)
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/MyDB");

// 從池取得邏輯連接
Connection conn = ds.getConnection(); // 實際從池取出可用連接
try {
    // 業務操作
} finally {
    conn.close(); // 不關閉物理連接，歸還給池
}

關鍵差異： getConnection() 從池取得已建立連接；close() 歸還池而非銷毀。現代應用伺服器 (WebLogic, WebSphere, JBoss 等) 皆內建支援 JDBC 2.0 連接池，採雙層架構：池位於應用伺服器記憶體空間。

JMS 連接池：非同步訊息資源共享

JMS 1.02 同樣提供連接池介面：

• QueueConnectionFactory / TopicConnectionFactory：工廠介面
• QueueConnection / TopicConnection：連接介面

JMS 廠商通常以代理模式實作池化：open()/close() 轉發給池管理器。若 JMS 後端使用資料庫儲存訊息，可共用 JDBC 連接池。

JNDI LDAP 連接池：廠商擴展

JNDI LDAP API 未標準化連接池，由目錄服務廠商提供 SDK 支援。例：iPlanet Netscape Directory SDK：

netscape.ldap.util.ConnectionPool cp = ...;
cp.getConnection(); // 從池取得 LDAP 連接

J2EE Connector Architecture 1.0 (JCA)：統一資源適配器標準

上述方案皆需 EJB 依賴廠商特定類別，降低可移植性。JCA 定義通用契約：

核心概念：資源適配器

• Resource Adapter：每種資源類型的可插拔元件，運行於應用伺服器位址空間
• Common Client Interface (CCI)：統一客戶端 API
  • javax.resource.cci.ConnectionFactory：連接工廠
  • javax.resource.cci.Connection：連接介面
• 應用伺服器提供 ConnectionManager 管理連接池、交易、安全性

JCA 連接池運作流程

1. EJB 透過 JNDI 查詢 ConnectionFactory
2. 呼叫 getConnection()
3. ConnectionManager 委派請求：
4. 池中有可用連接 → 直接回傳
5. 池無可用 → 使用 ManagedConnectionFactory 建立物理連接

應用伺服器可根據適配器類型、QoS 需求劃分多個連接池。例：Sun iPlanet Unified Integration Framework 為每個後端系統定義專屬連接池，由定期執行緒監控池物件生命週期。

EJB 層設計考量：連接池不是萬靈丹

錯誤模式：在 setSessionContext 中長期持有連接

public class BadBean implements SessionBean {
    private LDAPConnection lc; // 實例欄位持有連接
    public void setSessionContext(SessionContext sc) {
        ConnectionPool cp = (ConnectionPool) ctx.lookup(cpsource);
        this.lc = cp.getConnection(); // 會話期間持續佔用！
    }
}

後果：

1. 佔用連接池資源，併發用戶增多時池耗盡
2. 連接物件非序列化，EJB 容器鈍化時可能拋棄 Bean 實例導致連接洩漏

正確模式：在業務方法中短暫借用/歸還

public void ejbActivate() {
    // 從池取得連接
    this.conn = pool.getConnection();
}
public void ejbPassivate() {
    // 歸還連接給池
    if (this.conn != null) pool.returnConnection(this.conn);
}
public void businessMethod() {
    // 使用已取得的連接
}

有了連接池，獲取/釋放開銷極低，此模式可行且安全。

認證與安全性考量

池化連接意味著共享連接，預設使用單一認證憑證 (啟動時配置)。若應用需依用戶身分存取資源 (如 LDAP 子樹權限)，可考慮：

• 按認證憑證分池 (不同憑證對應不同池)
• 應用層實作安全檢查，資源層使用通用連接

結語

連接池是 J2EE 高效能的基石。從 JDBC 2.0 標準化開始，到 JCA 統一資源適配器契約，技術演進解決了可移植性與廠商鎖定問題。但工具再好，設計選擇才是關鍵：短借速還、避免長期持有、根據安全需求規劃池策略，才能發揮連接池最大效能。