我們在Oracle 10數據庫（使用哈德森持續集成服務器）的前端運行我們的JUnit 4測試套件對Weblogic的9，偶爾我們會在腳本拆卸過程中遇到ORA-12519崩潰。但是，錯誤是非常間歇性：什麼會導致間歇性ORA-12519（TNS：沒有合適的處理程序中發現的）錯誤
雖然我不能保證對運行時，這不會發生在本地（同樣的數據庫，當然），我已經多次運行同一套班級，沒有任何問題。
任何想法？
不知道這是否會成爲每個人的答案，但一些挖後，這裏就是我們想出了。
該錯誤是明顯的事實，聽衆不接受連接造成的，但我們爲什麼會得到這個錯誤，當其他測試可以正常連接（我們也可以通過連接SQLPLUS沒問題）？問題的關鍵不在於我們無法連接，而是因爲它是間歇性的
經過一番調查後，我們發現有一些靜態數據在類設置期間創建，可以保持打開連接測試課程的生命，創造新的測試課程。現在，儘管當這個類超出範圍時（當然是通過finally {}塊），所有資源都被正確釋放，但是在運行期間，有些情況下這個類會吞噬所有可用的連接（好的，壞的練習警報 - 這是直接連接而不是使用池的單元測試代碼，因此在生產中不會發生同樣的問題）。
此修復程序是不會讓這個類的靜態和類別設置運行，而是在每個方法的建立和拆卸方法使用它。
所以，如果你在自己的應用中得到這個錯誤，一巴掌壞小子探查，看看你可能有一個連接泄漏。希望有所幫助。
另一種解決方案我發現了類似的錯誤，但相同的錯誤消息是增加發現服務處理程序的數目。 （我的這個錯誤的實例是通過在WebLogic門戶網站連接池連接過多造成的。）
SQL*Plus和登錄爲SYSTEM。您應該知道在安裝Oracle DB XE期間您使用過的密碼。alter system set processes=150 scope=spfile;從這裏：
我也有同樣的問題，我搜索的答案很多地方。我有很多類似的答案來改變流程/服務處理程序的數量。但我想，如果我忘了重置它，該怎麼辦？
然後我嘗試在我的connection.close();之後使用Thread.sleep()方法。
我不知道如何，但它至少對我來說至少起作用。
如果有人想嘗試並找出它的工作原理，請繼續。我也想知道它，因爲我是編程世界的初學者。
我有類似的問題。每當我運行一個包含SpringJUnit4ClassRunner的數據庫（Spring JDBC）測試包時，它就發生了，所以我解決了爲每個測試添加@DirtiesContext註釋以清理應用程序上下文並釋放所有資源的問題，因此每個測試都可以使用新的初始化的應用程序上下文。
我在單元測試中遇到了這個問題，它通過連接池打開了很多與數據庫的連接，然後在每次測試結束時「停止」連接池（實際上是ManagedDataSource）以釋放連接。我在測試套件中的某個時刻總是用完連接。
在我的測試teardown（）中添加了一個Thread.sleep（500），這解決了問題。我認爲發生的事情是，連接池stop（）釋放另一個線程中的活動連接，以便如果主線程繼續運行測試，那麼清理線程遠遠落後於Oracle服務器的連接。添加睡眠允許後臺線程釋放池中的連接。
由於數據庫服務器更大，並且存在健康的操作組合（不僅是無窮的數據庫連接/斷開連接操作），所以這在現實世界中的問題要少得多。
我的情況在細節上有很大的不同，但它也涉及到連接泄漏，所以謝謝指出我在正確的方向。 – 2011-10-13 20:17:24
同樣在這裏。我必須在連接對象上手動添加對`close（）`的調用。 – Jason 2014-02-27 02:18:13