在应用服务器中创建JNDI JDBC连接池时，我总是将类型指定为javax.sql.ConnectionPoolDataSource.我从来没有过多地考虑过这一点，因为相对于非池化连接，似乎总是更喜欢池化连接，这似乎是很自然的.
然而，在查看一些示例(specifically for Tomcat)时，我注意到它们指定了javax.sql.DataSource.此外，似乎有maxIdle和maxWait的设置，给人的印象是这些连接也是共用的.Glassfish还允许这些参数，无论 Select 的数据源类型如何.
javax.sql.DataSource是否集中在应用程序服务器(或Servlet容器)中？javax.sql.ConnectionPoolDataSource比javax.sql.DataSource(反之亦然)有什么好处(如果有的话)？是的，对于定义为JNDI上下文资源的数据源，Tomcat默认使用Apache DBCP池.
来自以下位置的文档: http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources个
注意-默认数据源支持 在Tomcat中是基于DBCP的 来自公用地的连接池 项目.但是，有可能 使用任何其他符合以下条件的连接池 通过以下方式实现javax.sql.DataSource 编写您自己的自定义资源 工厂，如下所述.
挖掘Tomcat6源代码发现，他们是通过这种方式获得连接工厂的(如果您没有使用上下文的"Factory"属性指定自己的连接工厂):
ObjectFactory factory = (ObjectFactory)Class.forName(System.getProperty("javax.sql.DataSource.Factory", "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory")).newInstance();
和组织.apache .公cat dbcp.dbcp.实现javax的BasicDataSourceFactory.命名.spi.ObjectFactory负责创建数据源实例:
我看到他们创建了org的实例.apache .公cat dbcp.dbcp.资料来源:
奇怪的是，这个类本身没有实现ConnectionPoolDataSource，org也没有.apache .公cat dbcp.dbcp.PoolgDataSource，由BasicDataSource内部返回
因此，我假设当您将DataSource配置为javax.sql.ConnectionPoolDataSource时，您也使用了一些自定义的工厂(这只是一个猜测，但我想，否则您在Tomcat中就会有类强制转换异常，因为它们的池实际上并不提供javax.sql.ConnectionPoolDataSource的实例，而只提供javax.sql.DataSource的实例).
因此，要回答有关特定情况的优点或缺点的问题，您应该将Apache DBCP与您的数据源工厂中的池机制进行比较，无论您使用哪种机制.