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天真,复杂,过时.