| 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还是其他的数据库连接池，都应当具备一下基本功能：
-对源数据库资源的保护
-充分利用发挥数据库的有效资源
-简化应用的数据库接口，封闭资源管理。
-对应用遗留资源的自动回收和整理，提高资源的再次利用率。
在这个前提下，应用程序才能投入更多的精力于各自的业务逻辑中。数据库资源也不再成为系统的瓶颈。 |
