oracle.jdbc.pool.OracleConnectionPoolDataSource ， com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource 这两个来自各自的 jdbc 驱动里面的类看上去是如此相似，但事实上实现的却是两样事情。

　　OracleConnectionPoolDataSource 确实是一个 Connection Pool 实现，算得上是最轻量级的 Oracle 数据库连接池实现方式；而 MysqlConnectionPoolDataSource 实际上只是一个提供给 ConnectionPool 使用的 DataSource 而已，并没有任何的连接池功能。

　　所以如果你熟悉 OracleConnectionPoolDataSource 的话，可能会被 mysql Connector/J 驱动引擎里面的这个 MysqlConnectionPoolDataSource 类的名字给欺骗而把它当作连接池来使用。带来的结果就是无穷的 connection leak 。但这一点似乎 MySQL 在官方的 Manual 里面并没有很清晰的说明，以至于有人只好通过分析它的源代码来推测其实际的意义。倒是在MySQL Forum 里面 Mark Matthews 做了有一段很明确的解释：

1. Unless you're an application server vendor (or you are installing Connector/J into an application server that wants to use ConnectionPoolDataSources such as IBM Websphere), you shouldn't be using MysqlConnectionPoolDataSource
2. In any case, the physical connection does not go away until you call PooledConnection.close(), calling conn.close() only closes the 'logical' connection, which requires that any listeners on the ConnectionPoolDataSource be called so that it can _reclaim_ but not close the physical connection so that it can be handed out again, and
3. You're using very old versions of both Connector/J and MySQL and might want to consider upgrading (Connector/J is at 3.0.16 and the last release of MySQL 4.0 is at 4.0.24 currently, although the 'current' stable release is 4.1.10).
   
   ConnectionPoolDataSources are _not_ connection pools! They are 'vendors' of connections to connection pooling code. If you don't have your own connection pooling code, then you definitely don't want to be going this route!

　　所以目前来说 mysql Connector/J 里面并没有一个能像使用 OracleConnectionPoolDataSource 那样在 java 程序里面简便的实现 MySQL 数据库 connection pooling 的实现。你必须自己实现或者使用第三方的连接池实现，比如 c3p0 和  proxool 。