DBCP (Apache Commons Database Connection Pooling)是否仍然适用？

Question

JDBC 3.0规范讨论了连接(和准备好的语句)池。

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

我们正在使用MySQL (连接器/J)，并最终将添加SQL Server支持(jTDS)；我们不太可能支持任何其他数据库。

编辑:请参阅下面关于我尝试消除连接池程序库的评论。看起来DBCP仍然是相关的(请注意，一些评论者推荐使用C3P0而不是DBCP)。

Answer 1

基于其他帖子的鼓励，我尝试删除DBCP并直接使用连接器JDBC驱动程序( MySQL /J 5.0.4)。我不能这样做。

看起来，虽然驱动程序确实提供了池化的基础，但它并没有提供最重要的东西:实际的池(源代码对此很有用)。这一部分由应用程序服务器提供。

我又看了一遍JDBC3.0文档(我有一份打印的、标有“第11章连接池”的东西，不确定它的确切来源)，我可以看到MySQL驱动程序正在遵循JDBC文档。

当我看着DBCP时，这个决定开始有意义了。良好的池管理提供了许多选择。例如，何时清除未使用的连接？您会清除哪些连接？池中的最大连接数有硬限制还是软限制？在将连接提供给调用者之前，是否应该测试连接的“活性”？等。

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

Answer 2

DBCP存在严重缺陷。我不认为它适合于生产应用程序，特别是当如此多的驱动程序本身就支持DataSource池化的时候。

在我的例子中，压垮骆驼的稻草是，当我发现在向数据库进行新的连接尝试时，整个池都被锁定了。因此，如果您的数据库发生了导致连接缓慢或超时的情况，当其他线程尝试将连接返回到池时，即使它们是使用数据库完成的，它们也会被阻塞。

池的目的是提高性能，而不是降低性能。DBCP是幼稚、复杂和过时的。

Answer 3

我更喜欢使用dbcp或c3p0，因为它们是厂商中立的。我发现，至少在mysql或oracle中，每当我试图用jdbc客户机做一些非标准sql的事情时，我就必须在供应商的类上引入编译时依赖。例如，请参阅一个非常烦人的示例here。

我不太确定mysql，但是oracle使用他们特定的、非标准的类来实现连接池。