周末检到本J2EE的书翻了两下(1200多页，我靠），其中有提到JDBC的连接池，小有兴趣，因为我的VC-ADO程序也可以考虑实现个简单连接池来用用。
ADO的连接有几个特点：
1.它不是线程安全的。容易造成事务死锁。一般单条sql的不会死锁，但比如执行事务或游标时就很容易死锁掉.所以一般的多线程程序不提倡重用同一个ADO Connection
2:ADO会自己管理OLEDB连接池，当调用Connection的close方法，仅仅是将连接放到池里，直到超时或程序关闭。一般来说，一个程序使用相同连接串创建的连接都会被自动池化。ADO.net可以明确的选择是否使用池。
3：如果使用智能指针_ConnectionPrt,其Close方式只是关闭连接（放到池），而没有释放对象。
4：但如果一直不调用Close,该连接则无法被其他线程/进程共享
5：在某个连接上忙，且程序要求在该连接上执行操作的时候，ADO其实会打开一个临时连接供使用。
之所以考虑ADO的连接池，主要是执行一些简单的sql时（如insert,delete..)，不需要多创建很多ADO Connection对象。
另外也随便记录一点设计一个池要考虑的一些要素：
１：池化。包括批次初始化和释放连接。可以设计成忙／闲队列管理，一有调用，就从闲队列里取出一个，并将其引用放到忙队列里；或者采用循环数组，通过记数管理。倾向于使用后者，因为前者最多的连接数不能超出队列大小，而实际上每个连接是可以被客户端复用的。记数管理的目的是获取连接池里被引用最少的一个连接。
２：给客户端统一的获取和释放接口。Pool.GetConnection这个好理解。也可以定义一个Pool.ReleaseConnection(Connection)接口，但客户端代码难免会习惯性的调用Connection.Close（即使禁止）。最好的办法就是实现或者说重载Connection接口，接管或屏蔽Close.使Close的默认动作是将连接返回Pool里待用（或者减少在连接上的使用记数).
3:检测连接上的事务完成状态。在一个复用的连接上交叉执行事务是不应该的。在一个事务没有执行完毕时，不允许加入另一个事务（通过进程内锁实现）。但目前编写的代码基本上没有使用到transaction的，所以不着急。
４：从２可以看到，最好是定义一个PooledConnection接口，客户端对接口实例操作，而不是直接对Connection对象操作，这样才能更好的实现池化的一些控制逻辑。但这样又牵涉到接口和对象间的同步维护。最好是用继承的方法实现，除了打开关闭等直接影响连接状况的接口外，还是给客户端对对象的大部分直接控制接口。
５：连接池应检测Connection的连接状态，断连的连接应该被标记或直接移出连接池。
