为什么同时使用C3PO和JNDI会产生问题？

Question

我正在运行一个使用Tomcat 8服务器中的Hibernate的应用程序.我想利用除Hibernate之外的其他连接池,因为它们很明显它不适合在生产环境中使用.

此外,他们提到:

要在应用程序服务器中使用,您几乎应该始终配置Hibernate以从JNDI中注册的应用程序服务器javax.sql.Datasource获取连接.

所以我似乎需要做两件事:

1. 配置Hibernate以使用第三方连接池 - Hibernate建议使用C3PO
2. 配置Hibernate以从javax.sql.DatasourceJNDI中注册的对象获取连接

我一直在研究如何进行这些改变,我遇到了这个问题.海报已经在使用C3PO,并询问如何通过JNDI Datasource对象连接到他们的数据库.然而,他们遇到了问题,因为他们已经在使用C3PO,而他们正在遵循回答者使用JNDI数据源的步骤.海报在接受的答案的评论部分说明了这一点:

是的,我一直在使用c3p0和JNDI做傻事.我删除了所有的c3p0配置,现在工作正常.

Hibernate建议使用第三方连接池,即C3PO,并使用JNDI数据源来接收连接,但它似乎对该用户造成了问题; 他们甚至谈到同时使用它们就好像这是一个明显的错误.

那么我可以不同时使用它们,还是应该像Hibernate推荐的那样使用它们？我所要做的就是将Hibernate的默认连接池替换为打算在生产环境中使用的池,并且还配置Hibernate以获取来自javax.sql.DatasourceJNDI中注册的对象的连接,正如他们所推荐的那样.

Answer 1

我会尽力消除混乱。

我认为它始于令人惊讶的简单 DataSource 接口：https://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html

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

1. 基本实现——生成一个标准的 Connection 对象
2. 连接池实现——生成一个连接对象，该对象将自动参与连接池。此实现与中间层连接池管理器一起使用。
3. 分布式事务实现——生成一个可用于分布式事务的 Connection 对象，并且几乎总是参与连接池。此实现与中间层事务管理器一起使用，并且几乎总是与连接池管理器一起使用。

Hibernate 需要一个数据源来工作，并建议它使用连接池。

C3PO 包装现有的 DataSource 并向其应用连接池，并创建一个类型 2 的新 DataSource。C3PO 假定它获取的 DataSource 是类型 1，但无法确定。

在其他应用程序服务器中，如果您声明在 JNDI 中注册的数据源，它几乎总是使用容器中已有的连接池。对于 Tomcat 8，它在内部使用 C3PO。

因此，在 Hibernate 中实现连接池有两种方法：要么创建一个类型 1 数据源并将其嵌入到代码中的连接池中，要么在容器中声明您的数据源（带有连接池），然后从 JNDI 将其注入到 hibernate 中。

如果您同时执行这两项操作（如您的情况），应用程序中的 C3PO 会从 JNDI 获取数据源，该数据源本身就是由 tomcat 管理的 C3PO 数据源。当应用程序尝试获取连接时，应用程序 C3PO 将调用容器 C3PO，容器 C3PO 将创建实际连接，但该连接将集中在两个连接池中。当hibernate释放连接时，应用程序C3PO将保留它以供重用，但其他连接池也会继续等待连接被释放。

根据配置，底层连接池可能会在一定的超时后终止连接。

因此，配置两个相互叠加的连接池是危险的，也是完全没有必要的。

回答赏金问题：在生产环境中，在生产容器中声明数据源并通过 JNDI 将其连接到 Hibernate，而无需在 Hibernate 中配置任何其他连接池。