java 应用程序服务器 JDBC 资源的 DataSource 或 ConnectionPoolDataSource

DataSource or ConnectionPoolDataSource for Application Server JDBC resources

提问by Vinnie

When creating JNDI JDBC connection pools in an application server, I always specified the type as javax.sql.ConnectionPoolDataSource. I never really gave it too much thought as it always seemed natural to prefer pooled connections over non-pooled.

在应用程序服务器中创建 JNDI JDBC 连接池时，我总是将类型指定为javax.sql.ConnectionPoolDataSource. 我从来没有真正考虑过它，因为更喜欢池连接而不是非池连接似乎总是很自然。

However, in looking at some examples (specifically for Tomcat) I noticed that they specify javax.sql.DataSource. Further, it seems there are settings for maxIdleand maxWaitgiving the impression that these connections are pooled as well. Glassfish also allows these parameters regardless of the type of data source selected.

但是，在查看一些示例（特别是 Tomcat）时，我注意到它们指定了javax.sql.DataSource. 此外，似乎有设置maxIdle并maxWait给人的印象是这些连接也是池化的。Glassfish 也允许使用这些参数，而不管选择的数据源类型如何。

• Are javax.sql.DataSourcepooled in an application server (or servlet container)?
• What (if any) advantages are there for choosing javax.sql.ConnectionPoolDataSourceover javax.sql.DataSource(or vice versa)?

• 是否javax.sql.DataSource在应用程序服务器（或 servlet 容器）中汇集？
• 什么（如果有的话）的优势在那里为选择javax.sql.ConnectionPoolDataSource了javax.sql.DataSource（反之亦然）？

采纳答案by mvmn

Yes, Tomcat does use Apache DBCP pooling by default for DataSources defined as JNDI Context resources.

是的，默认情况下，Tomcat 确实对定义为 JNDI 上下文资源的数据源使用 Apache DBCP 池。

From documentation at http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

来自http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources 的文档

NOTE - The default data source support in Tomcat is based on the DBCP connection pool from the Commons project. However, it is possible to use any other connection pool that implements javax.sql.DataSource, by writing your own custom resource factory, as described below.

注意 - Tomcat 中的默认数据源支持基于来自 Commons 项目的 DBCP 连接池。但是，通过编写您自己的自定义资源工厂，可以使用任何其他实现 javax.sql.DataSource 的连接池，如下所述。

Digging Tomcat 6 sources revealed that they obtain connection factory this way (in case when you don't specify your own using Context's "factory" attribute):

挖掘 Tomcat 6 源发现它们以这种方式获取连接工厂（如果您没有使用 Context 的“工厂”属性指定自己的工厂）：

ObjectFactory factory = (ObjectFactory)Class.forName(System.getProperty("javax.sql.DataSource.Factory", "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory")).newInstance();

And org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory that implements javax.naming.spi.ObjectFactory takes care of creating DataSource instances: http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSourceFactory.java?format=ok

实现 javax.naming.spi.ObjectFactory 的 org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory 负责创建 DataSource 实例：http: //www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat- dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSourceFactory.java?format=ok

I see they create instances of org.apache.tomcat.dbcp.dbcp.BasicDataSource: http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSource.java?format=ok

我看到他们创建了 org.apache.tomcat.dbcp.dbcp.BasicDataSource 的实例：http: //www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp- 7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSource.java?format=ok

Oddly enough, this class doesn't implement ConnectionPoolDataSource itself, neither does org.apache.tomcat.dbcp.dbcp.PoolingDataSource, that's returned internally by BasicDataSource http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/PoolingDataSource.java?format=ok

奇怪的是，这个类没有实现 ConnectionPoolDataSource 本身，org.apache.tomcat.dbcp.dbcp.PoolingDataSource 也没有实现，它是由 BasicDataSource 内部返回的 http://www.jarvana.com/jarvana/view/org/apache/tomcat /tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/PoolingDataSource.java?format=ok

So I presume when you configured your DataSources as javax.sql.ConnectionPoolDataSource you also used some custom-defined factory (it's just a guess, but I suppose otherwise you'd have class cast exceptions in Tomcat, since their pooling doesn't really provide instances of javax.sql.ConnectionPoolDataSource, only javax.sql.DataSource).

因此，我认为当您将 DataSources 配置为 javax.sql.ConnectionPoolDataSource 时，您还使用了一些自定义工厂（这只是一个猜测，但我想否则您会在 Tomcat 中出现类转换异常，因为它们的池并没有真正提供javax.sql.ConnectionPoolDataSource 的实例，只有 javax.sql.DataSource）。

Thus, to answer questions about advantages or disadvantages of particular case you should compare Apache DBCP against pooling mechanism in your DataSource factory, whichever one you used.

因此，要回答有关特定情况的优缺点的问题，您应该将 Apache DBCP 与 DataSource 工厂中的池机制进行比较，无论您使用哪种。

回答by MrJames

As for the Java docs it contains this:

至于 Java 文档，它包含以下内容：

DataSource Java 7 API

数据源 Java 7 API

The DataSource interface is implemented by a driver vendor. There are three types of implementations:

Basic implementation -- produces a standard Connection object

Connection pooling implementation -- produces a Connection object that will automatically participate in connection pooling. This implementation works with a middle-tier connection pooling manager.

Distributed transaction implementation -- produces a Connection object that may be used for distributed transactions and almost always participates in connection pooling. This implementation works with a middle-tier transaction manager and almost always with a connection pooling manager.

DataSource 接口由驱动程序供应商实现。有三种类型的实现：

基本实现——产生一个标准的 Connection 对象

连接池实现——产生一个将自动参与连接池的 Connection 对象。此实现与中间层连接池管理器一起使用。

分布式事务实现——产生一个可用于分布式事务的 Connection 对象，并且几乎总是参与连接池。此实现与中间层事务管理器一起使用，并且几乎总是与连接池管理器一起使用。

PooledConnection Java 7 API

池化连接 Java 7 API

An application programmer does not use the PooledConnectioninterface directly; rather, it is used by a middle tier infrastructure that manages the pooling of connections.

When an application calls the method DataSource.getConnection, it gets back a Connection object. If connection pooling is being done, that Connection object is actually a handle to a PooledConnection object, which is a physical connection.

The connection pool manager, typically the application server, maintains a pool of PooledConnectionobjects ....

一个应用程序的程序员不使用的PooledConnection直接接口; 相反，它由管理连接池的中间层基础设施使用。

当应用程序调用 DataSource.getConnection 方法时，它会返回一个 Connection 对象。如果正在进行连接池，则该 Connection 对象实际上是 PooledConnection 对象的句柄，它是一个物理连接。

连接池管理器，通常是应用程序服务器，维护一个 PooledConnection对象池......

So in the end you just use DataSourceand Connectionclasses and never PooledConnection / ConnectionPoolDataSource, if you are a happy and normal programmer.

所以最后你只使用DataSource和Connection类，而不是PooledConnection / ConnectionPoolDataSource，如果你是一个快乐和正常的程序员。

If are implementing an Application Server that's another story...

如果正在实施应用服务器，那就是另一回事了……

回答by Sergey Aslanov

My understanding is that only purpose of ConnectionPoolDataSourceis to give access to PooledConnectionwhich implements nativepooling by JDBC driver. In this case application server can implement connections pooling using this native interface.

我的理解是， 的唯一目的ConnectionPoolDataSource是通过 JDBC 驱动程序访问PooledConnection实现本机池的对象。在这种情况下，应用服务器可以使用这个本地接口实现连接池。

When using simple DataSource, appserver uses its own pooling instead of native.

使用 simple 时DataSource，appserver 使用自己的池而不是本机。

Can't say which approach is best.

不能说哪种方法最好。