在应用程序服务器环境中，是否应该更喜欢javax.sql.DataSource或javax.sql.ConnectionPoolDataSource？ [英] In an application server environment, should one prefer javax.sql.DataSource or javax.sql.ConnectionPoolDataSource?

问题描述

现有问题表达类似的内容，但我想要在这里引出一个稍微不同的细微差别。

An existing question expresses something similar, but I want to call out a slightly different nuance here.

基本问题：所有应用服务器都能够指定两个（标准）接口定义连接池时，和（little-d，little-s）数据源的（供应商提供的）实现类。如果供应商为 ConnectionPoolDataSource 和常规ol' DataSource 提供实现，哪一个是首选？

The basic question: All application servers give the ability to specify both the (standard) interface and the (vendor-supplied) implementation classes for a (little-d, little-s) data source when you define a connection pool. If a vendor supplies an implementation for both a ConnectionPoolDataSource and a regular ol' DataSource, which one is to be preferred?

实现 DataSource 的供应商实现怎么样， ConnectionPoolDataSource 和 XADataSource 在同一个实现类中？

What about for vendor implementations that implement DataSource, ConnectionPoolDataSource and XADataSource in the same implementation class?

javax.sql的文档。 ConnectionPoolDataSource 几乎总是说：

PooledConnection对象的工厂。实现此接口的对象通常将使用基于JavaTM命名和目录接口（JNDI）的命名服务进行注册。

A factory for PooledConnection objects. An object that implements this interface will typically be registered with a naming service that is based on the JavaTM Naming and Directory Interface (JNDI).

这基本上没用，但值得注意的是 javax.sql.ConnectionPoolDataSource 本身不会扩展 javax.sql.DataSource ，这意味着它的实现不需要提供 getConnection（）方法，这是大多数调用者习惯使用的方法。这告诉我所有应用程序服务器必须：

That's basically useless, but it is worth noting that javax.sql.ConnectionPoolDataSource does not itself extend javax.sql.DataSource, which means that implementations of it need not provide a getConnection() method, which is the one most callers are accustomed to using. This tells me that all application servers MUST either:

• 包装 javax.sql.ConnectionPoolDataSource javax.sql.DataSource 实现code>实现，以便调用者可以使用 javax.sql.DataSource＃getConnection（），或

• wrap a javax.sql.ConnectionPoolDataSource implementation with a javax.sql.DataSource implementation so that callers can use javax.sql.DataSource#getConnection(), or

检测到 javax.sql.ConnectionPoolDataSource 实现还一个 javax.sql.DataSource 实现，并且（不知何故）相信它的 getConnection（）方法委托给 getPooledConnection（）（他们怎么会这样做？）

detect that a javax.sql.ConnectionPoolDataSource implementation is also a javax.sql.DataSource implementation, and (somehow) trust that its getConnection() method will delegate to getPooledConnection() (how on earth would they do this?)

javax.sql.DataSource 的文档部分说：

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

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

• 基本实现 - 生成标准Connection对象


• 连接池实现 - 生成一个将自动参与连接池的Connection对象。此实现适用于中间层连接池管理器。


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

这也是无用的，并且引导不正确（或至少未指定： javax.sql.DataSource 也由应用服务器供应商实现，他们必须提供实现以便客户端代码可能（例如）将 javax.sql.DataSource 注入其服务器端代码中。它似乎也暗示任何给定的 DataSource 实现可能会或可能不会提供连接池，这会让我想知道应用程序服务器应该如何告诉连接池设置已指定 javax.sql.DataSource 接口（而不是 javax.sql.ConnectionPoolDataSource 接口） 。

This is also useless, and incorrect to boot (or at least underspecified: javax.sql.DataSource is also implemented by application server vendors, who must provide an implementation so that client code may (for example) inject a javax.sql.DataSource into their server-side code). It also seems to imply that connection pooling might or might not be offered by any given DataSource implementation, which would make me wonder how an application server is supposed to tell when a connection pool is set up that has specified the javax.sql.DataSource interface (instead of the javax.sql.ConnectionPoolDataSource interface).

注意：我不是在寻找关于我如何在Tomcat上做到这一点的答案，或者我在GlassFish上采取的步骤对我来说或任何性质的东西。我正在寻找一个回答JDBC规范，Java EE规范或错误报告的答案，或者说明为什么存在这些独立（无关！）接口的原因，以及它们应该如何统一或区分在一个通用的Java EE应用服务器上，因此有义务提供连接池。

Note: I am not looking for an answer here about How I Did This On Tomcat, or The Steps I Took On GlassFish That Worked For Me or anything of that nature. I'm looking for an answer that refers back to the JDBC specification, or the Java EE specification, or a bug report, or something that indicates why these separate (unrelated!) interfaces exist, and how they are supposed to be unified or distinguished between on a generic Java EE application server that is therefore obligated to offer connection pooling.

推荐答案

只是为了解释一下：
我正在使用Postgres，并且来自PGConnectionPoolDataSource的API文档对我来说非常清楚：

Just to shed some light: I'm using Postgres, and the API doc from PGConnectionPoolDataSource is quite clear for me:

public class PGConnectionPoolDataSource
extends org.postgresql.ds.jdbc4.AbstractJdbc4ConnectionPoolDataSource
implements javax.sql.ConnectionPoolDataSource

ConnectionPoolDataSource的PostgreSQL实现。应用服务器
或中间件供应商应提供一个数据源实现，
利用此ConnectionPoolDataSource。如果没有，你可以使用
PostgreSQL实现称为PoolingDataSource，但只有在你的服务器或中间件供应商不是$时才能使用
b $ b提供自己的。为什么？服务器可能希望在同一
事务中请求连接的所有EJB重用相同的
连接，或者提供其他类似的高级功能。

PostgreSQL implementation of ConnectionPoolDataSource. The app server or middleware vendor should provide a DataSource implementation that takes advantage of this ConnectionPoolDataSource. If not, you can use the PostgreSQL implementation known as PoolingDataSource, but that should only be used if your server or middleware vendor does not provide their own. Why? The server may want to reuse the same Connection across all EJBs requesting a Connection within the same Transaction, or provide other similar advanced features.

这篇关于在应用程序服务器环境中，是否应该更喜欢javax.sql.DataSource或javax.sql.ConnectionPoolDataSource？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！