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是幼稚的，复杂的和过时的。
