JDBC 3.0规范讨论了连接（和准备语句）池。
我们有几个独立的Java程序（即我们没有使用应用程序服务器），它们一直使用DBCP来提供连接池。我们应该继续使用DBCP，还是可以利用JDBC提供的池并摆脱DBCP？
我们正在使用MySQL（Connector / J）并最终将添加SQL Server支持（jTDS）;我们不太可能支持任何其他数据库。
编辑：请参阅下面有关我尝试删除连接池库的注释。似乎DBCP仍然相关（请注意，一些评论者推荐C3P0而不是DBCP）。
答案 0 :(得分：13)
基于其他海报的鼓励，我试图消除DBCP并直接使用MySQL JDBC驱动程序（Connector / J 5.0.4）。我无法这样做。
虽然驱动程序确实为池化提供了基础，但它并没有提供最重要的东西：实际的池（源代码为此派上了用场）。由应用程序服务器提供此部分。
我再看一下JDBC 3.0文档（我有一个标记为“第11章连接池”的打印副本，不确定它来自何处）我可以看到MySQL驱动程序遵循JDBC文档。
当我看到DBCP时，这个决定开始变得有意义了。良好的池管理提供了许多选择。例如，何时清除未使用的连接？你清除哪些连接？池中的最大连接数是硬限制还是软限制？你应该在将它传给呼叫者之前测试一个“活跃”的连接吗？等
总结：如果您正在使用独立的Java应用程序，则需要使用连接池库。连接池库仍然相关。
答案 1 :(得分：7)
DBCP存在严重缺陷。我认为它不适合生产应用程序，特别是当很多驱动程序支持在DataSource本地使用池时。
在我的情况下，打破了骆驼背部的稻草，当我发现整个游泳池被锁定时，一直都是对数据库进行新的连接尝试。因此，如果您的数据库发生某些事情导致连接速度变慢或超时，则当其他线程尝试将连接返回到池时会被阻止 - 即使它们是使用数据库完成的。
池旨在提高性能，而不是降低性能。 DBCP天真，复杂，过时。
答案 2 :(得分：1)
我更喜欢使用dbcp或c3p0，因为它们是供应商中立的。我发现，至少使用mysql或oracle，每当我尝试使用非标准sql的jdbc客户端时，我必须在供应商的类中引入编译时依赖性。例如，请参阅一个非常恼人的示例here。
我不确定mysql，但oracle使用他们特定的非标准类进行连接池。
答案 3 :(得分：0)
人们仍然使用DBCP，我认为它甚至是Hibernate的默认设置。
DBCP无法满足您当前的需求吗？
我不是替换基础设施的忠实信徒，除非已经存在无法填补的性能或功能差距，即使有更新或更有趣的替代方案。