DBCP（Apache Commons Database Connection Pooling）仍然相关吗？

JDBC 3.0规范讨论了连接（和准备语句）池。

我们有几个独立的Java程序（即我们没有使用应用程序服务器），它们一直使用DBCP来提供连接池。我们应该继续使用DBCP，还是可以利用JDBC提供的池并摆脱DBCP？

我们正在使用MySQL（Connector / J）并最终将添加SQL Server支持（jTDS）; 我们不太可能支持任何其他数据库。

编辑：请参阅下面有关我尝试消除连接池库的注释。似乎DBCP仍然相关（注意一些评论者推荐C3P0而不是DBCP）。

基于其他海报的鼓励，我试图消除DBCP并直接使用MySQL JDBC驱动程序（Connector / J 5.0.4）。我无法这样做。

看起来虽然驱动程序确实为池化提供了基础，但它并没有提供最重要的东西：实际的池（源代码为此派上了用场）。由应用程序服务器提供此部分。

我再看一下JDBC 3.0文档（我有一个标记为“第11章连接池”的打印副本，不确定它来自何处）我可以看到MySQL驱动程序遵循JDBC文档。

当我看到DBCP时，这个决定开始变得有意义了。良好的池管理提供了许多选择。例如，什么时候清除未使用的连接？你清除哪些连接？池中的最大连接数是硬限制还是软限制？你应该在将它传给呼叫者之前测试一个“活跃”的连接吗？等等

简介：如果您正在执行独立的Java应用程序，则需要使用连接池库。连接池库仍然相关。

DBCP存在严重缺陷。我不认为它适用于生产应用程序，特别是当这么多驱动程序本身支持其DataSource池时。

在我的情况下，打破骆驼背部的稻草，当我发现整个游泳池被锁定时，一直都在尝试对数据库进行新的连接尝试。因此，如果您的数据库发生某些事情导致连接速度慢或超时，则当其他线程尝试将连接返回到池时会被阻止 – 即使它们是使用数据库完成的。

池旨在提高性能，而不是降低性能。 DBCP天真，复杂，过时。

我更喜欢使用dbcp或c3p0，因为它们是供应商中立的。我发现，至少使用mysql或oracle，每当我尝试使用非标准sql的jdbc客户端时，我必须在供应商的类中引入编译时依赖性。例如，请参阅此处非常恼人的示例。

我不确定mysql，但oracle使用他们特定的非标准类进行连接池。

人们仍然使用DBCP，我认为它甚至是Hibernate的默认设置。

DBCP无法满足您当前的需求吗？

我不是更换基础设施的忠实信徒，除非已经存在无法填补的性能或function差距，即使有更新或更有趣的替代方案。