DBCP（Apache Commons Database Connection Pooling）仍然相關嗎？

Question

JDBC 3.0規范討論了連接（和准備語句）池。

我們有幾個獨立的Java程序（即我們沒有使用應用程序服務器），它們一直使用DBCP來提供連接池。 我們應該繼續使用DBCP，還是可以利用JDBC提供的池並擺脫DBCP？

我們正在使用MySQL（Connector / J）並最終將添加SQL Server支持（jTDS）; 我們不太可能支持任何其他數據庫。

編輯：請參閱下面有關我嘗試消除連接池庫的注釋。 似乎DBCP仍然相關（注意一些評論者推薦C3P0而不是DBCP）。

Answer 1

基於其他海報的鼓勵，我試圖消除DBCP並直接使用MySQL JDBC驅動程序（Connector / J 5.0.4）。 我無法這樣做。

看起來雖然驅動程序確實為池化提供了基礎，但它並沒有提供最重要的東西：實際的池（源代碼為此派上了用場）。 由應用程序服務器提供此部分。

我再看一下JDBC 3.0文檔（我有一個標記為“第11章連接池”的打印副本，不確定它來自何處）我可以看到MySQL驅動程序遵循JDBC文檔。

當我看到DBCP時，這個決定開始變得有意義了。 良好的池管理提供了許多選擇。 例如，何時清除未使用的連接？ 你清除哪些連接？ 池中的最大連接數是硬限制還是軟限制？ 你應該在將它傳給呼叫者之前測試一個“活躍”的連接嗎？ 等等

簡介：如果您正在執行獨立的Java應用程序，則需要使用連接池庫。 連接池庫仍然相關。

Answer 2

DBCP存在嚴重缺陷。 我不認為它適用於生產應用程序，特別是當這么多驅動程序本身支持其DataSource池時。

在我的情況下，打破駱駝背部的稻草，當我發現整個游泳池被鎖定時，一直都是對數據庫進行新的連接嘗試。 因此，如果您的數據庫發生某些事情導致連接速度慢或超時，則當其他線程嘗試將連接返回到池時會被阻止 - 即使它們是使用數據庫完成的。

池旨在提高性能，而不是降低性能。 DBCP天真，復雜，過時。

Answer 3

我更喜歡使用dbcp或c3p0，因為它們是供應商中立的。 我發現，至少使用mysql或oracle，每當我嘗試使用非標准sql的jdbc客戶端時，我必須在供應商的類中引入編譯時依賴性。 例如，請參閱此處非常惱人的示例。

我不確定mysql，但oracle使用他們特定的非標准類進行連接池。

Answer 4

人們仍然使用DBCP，我認為它甚至是Hibernate的默認設置。

DBCP無法滿足您當前的需求嗎？

我不是更換基礎設施的忠實信徒，除非已經存在無法填補的性能或功能差距，即使有更新或更有趣的替代方案。