一个现有的问题表达了类似的东西,但我想在这里指出一个稍微不同的细微差别。
基本问题:当您定义连接池时,所有应用程序服务器都能够为(little-d,little-s)数据源指定(标准)接口和(供应商提供的)实现类。如果供应商为 aConnectionPoolDataSource
和常规 ol'提供了实现DataSource
,那么哪个是首选?
对于实现DataSource
,ConnectionPoolDataSource
并且XADataSource
在同一个实现类中的供应商实现呢?
文档javax.sql.ConnectionPoolDataSource
说,几乎总而言之:
PooledConnection 对象的工厂。实现此接口的对象通常会向基于 JavaTM 命名和目录接口 (JNDI) 的命名服务注册。
这基本上没用,但值得注意的是javax.sql.ConnectionPoolDataSource
它本身并不扩展javax.sql.DataSource
,这意味着它的实现不需要提供getConnection()
方法,这是大多数调用者习惯使用的方法。这告诉我所有应用程序服务器必须:
用一个实现包装一个
javax.sql.ConnectionPoolDataSource
实现,javax.sql.DataSource
以便调用者可以使用javax.sql.DataSource#getConnection()
, 或检测到一个
javax.sql.ConnectionPoolDataSource
实现也是一个javax.sql.DataSource
实现,并且(以某种方式)相信它的getConnection()
方法将委托给getPooledConnection()
(他们到底将如何做到这一点?)
的文档javax.sql.DataSource
部分说:
DataSource 接口由驱动程序供应商实现。有三种类型的实现:
- 基本实现——产生一个标准的 Connection 对象
- 连接池实现——生成一个将自动参与连接池的连接对象。此实现与中间层连接池管理器一起使用。
- 分布式事务实现——生成一个可用于分布式事务并且几乎总是参与连接池的 Connection 对象。此实现与中间层事务管理器一起使用,并且几乎总是与连接池管理器一起使用。
这也是无用的,并且启动不正确(或至少未指定:javax.sql.DataSource
也由应用程序服务器供应商实现,他们必须提供一个实现,以便客户端代码可以(例如)将 ajavax.sql.DataSource
注入他们的服务器端代码)。这似乎也暗示任何给定的实现可能会或可能不会提供连接池DataSource
,这让我想知道应用程序服务器应该如何判断何时设置了指定javax.sql.DataSource
接口(而不是javax.sql.ConnectionPoolDataSource
接口)的连接池.
注意:我不是在这里寻找关于我在 Tomcat 上是如何做到的,或者我在 GlassFish 上采取的对我有用的步骤或任何类似性质的答案。我正在寻找一个参考 JDBC 规范、Java EE 规范或错误报告的答案,或者表明这些单独(不相关!)接口存在的原因,以及它们应该如何统一或区分的内容在通用 Java EE 应用程序服务器上,因此有义务提供连接池。