3.簡單JDBC連接池的實現
根據第二章中原理機制，Snap-ConnectionPool（一種簡單快速的連接池工具）按照部分的JDBC規范，實現了連接池所具備的對數據庫資源有效管理功能。
3.1體系描述
在JDBC規范中，應用通過驅動接口（Driver Interface）直接方法數據庫的資源。為了有效、合理地管理資源，在應用與JDBC Driver之間，增加了連接池： Snap-ConnectionPool.並且通過面向對象的機制，使連接池的大部分操作是透明的。參見下圖，Snap-ConnectionPool的體系：
圖中所示，通過實現JDBC的部分資源對象接口（ Connection， Statement， ResultSet ），在 Snap-ConnectionPool內部分別產生三種邏輯資源對象： PooledConnection， PooledStatement和 PooledResultSet.它們也是連接池主要的管理操作對象，並且繼承了JDBC中相應的從屬關系。這樣的體系有以下幾個特點：
-透明性。在不改變應用原有的使用JDBC驅動接口的前提下，提供資源管理的服務。應用系統，如同原有的 JDBC，使用連接池提供的邏輯對象資源。簡化了應用程序的連接池改造。
-資源封裝。復雜的資源管理被封裝在 Snap-ConnectionPool內部，不需要應用系統過多的干涉。管理操作的可靠性、安全性由連接池保證。應用的干涉（如：主動關閉資源），只起到優化系統性能的作用，遺漏操作不會帶來負面影響。
-資源合理應用。按照JDBC中資源的從屬關系，Snap-ConnectionPool不僅對Connection進行緩沖處理，對Statement也有相應的機制處理。在2.3已描述，合理運用Connection和Statement之間的關系，可以更大限度地使用資源。所以，Snap-ConnectionPool封裝了Connection資源，通過內部管理PooledConnection，為應用系統提供更多的Statement資源。
-資源連鎖管理。Snap-ConnectionPool包含的三種邏輯對象，繼承了JDBC中相應對象之間的從屬關系。在內部管理中，也依照從屬關系進行連鎖管理。例如：判斷一個Connection是否超時，需要根據所包含的Statement是否活躍；判斷Statement也要根據ResultSet的活躍程度。
3.2連接池集中管理ConnectionManager
ConnectionPool是Snap-ConnectionPool的連接池對象。在Snap-ConnectionPool內部，可以指定多個不同的連接池（ConnectionPool）為應用服務。ConnectionManager管理所有的連接池，每個連接池以不同的名稱區別。通過配置文件適應不同的數據庫種類。如下圖所示：
通過ConnectionManager，可以同時管理多個不同的連接池，提供通一的管理界面。在應用系統中通過ConnectionManager和相關的配置文件，可以將凌亂散落在各自應用程序中的數據庫配置信息（包括：數據庫名、用戶、密碼等信息），集中在一個文件中。便於系統的維護工作。
3.3 連接池使用范例
對2.1的標准JDBC的使用范例，改為使用連接池，結果如下：
import java.sql.*;
import net.snapbug.util.dbtool.*;
…
..ConnectionPool dbConn = ConnectionManager
.getConnectionPool("testOracle" );
Statement st = dbConn.createStatement();
ResultSet rs = st.executeQuery(
“select * from demo_table” );
…
some data source operation
in herers.close();st.close();
在例子中，Snap-ConnectionPool封裝了應用對Connection的管理。只要改變JDBC獲取Connection的方法，為獲取連接池（ConnectionPool）（粗體部分），其他的數據操作都可以不做修改。按照這樣的方式，Snap-ConnectionPool可幫助應用有效地管理數據庫資源。如果應用忽視了最後資源的釋放： rs.close（） 和 st.close（），連接池會通過超時（time-out）機制，自動回收。
4.小結
無論是Snap-ConnectionPool還是其他的數據庫連接池，都應當具備一下基本功能：
-對源數據庫資源的保護
-充分利用發揮數據庫的有效資源
-簡化應用的數據庫接口，封閉資源管理。
-對應用遺留資源的自動回收和整理，提高資源的再次利用率。
在這個前提下，應用程序才能投入更多的精力於各自的業務邏輯中。數據庫資源也不再成為系統的瓶頸。
