多線程和數據庫連接

所以我想弄清楚我的數據庫連接的最佳實踐。我有一個大的.NET GUI作爲MySQL數據庫的前端。目前，我在應用程序加載時打開一個連接，並將其用於我需要的任何交互。但是，整個GUI是單線程的。多線程和數據庫連接

當我開始爲大型查詢添加BackgroundWorkers並執行時，我很擔心我的打開連接。例如，我知道我一次只能在該連接上打開一個dataReader。有了多個線程，用戶可以嘗試實例化更多。

爲應用程序保持一個打開的連接與爲每個交互打開一個新的連接有什麼優點/缺點？

這是什麼常見的設計模式？

Thanks-

喬納森

來源

2010-02-22 Jonathan

使用一個線程安全的連接池，並保持連接線程特定（不要在線程之間共享連接）。

我相信MySQL .NET連接框架附帶內置的一個。如果對所有連接使用相同的連接字符串，只需在連接字符串中添加「pooling = true」即可。（Source - 沒有超鏈接片段，因此請在表格中查找「池」）

此方法的缺點是某些線程會阻塞，直到連接可用。您需要在程序結構中對此進行解釋。

來源

2010-02-22 15:46:49 Randolpho

對於一個打開的連接，您應該對數據庫具有最大的吞吐量。然而，你最終在應用程序中編寫複雜的代碼來共享連接。

Here是關於資源共享模式的文章。這些例子都在Ada中，但我相信你仍然可以閱讀它。

來源

2010-02-22 15:49:08

連接到數據源可能非常耗時。爲了最小化開放連接的成本，ADO.NET使用稱爲連接池的優化技術，該技術可以最大限度地降低反覆打開和關閉連接的成本。 .NET Framework數據提供者對連接池的處理方式不同。

來自MSDN。

看到這裏Connection Pooling (ADO.NET)

來源

2010-02-22 15:52:21

有2種方式：

單連接 - 在這種情況下，連接創建1次，所有的請求之間分配，如果有大量的併發請求導致生產力損失，並且您必須控制自己保存線程。
每個請求的連接 - 在這種情況下，您必須在執行請求後立即打開連接並立即關閉連接。但同時打開的連接數量可能受到服務器的限制。在這裏，創建連接的開銷始終存在，但是使用線程安全連接池解決，這是很好的做法。

您需要分析和預測應用程序的行爲並選擇適當的路徑。如果你有一個簡單的應用程序，你可能不需要使用這個池。如果應用程序需要嚴重的負載和未來的可伸縮性，則使用這些池是正確的。

來源

2010-02-22 15:54:48

在決定走哪條路之前，我們已經做了一些測試。我的意思是在ConnectionAlwaysOpen或ConnectAndDisconnectEachTime之間。

顯然從使用SQL Server的.NET（從來沒有用MySQL試過），在任何一種方法中都沒有可見的性能損失（毫無意外，因爲低層不會立即在ConnectAndDisconnectEachTime方案中立即斷開連接）。但有一個細微的差異，使我們決定爲ConnectionAlwaysOpen。原因是交易支持。如果你打算使用交易，那麼連接/斷開連接將不起作用，我想這顯然是爲什麼。

當然ConnectionAlwaysOpen可以使用現有的連接池或連接池的一些手動懶惰高速緩存來改善，但基本思路保持不變。在另一方面，在Web應用程序中這是一個有點難以實現，線程安全的這種做法，但它可能值得。

來源

2010-02-23 09:56:08 AureliusMarcus

當你說的事務支持是不可能的ConnectAndDisconnect情況下，你說的是一個「全球性」的交易，因爲應用程序的啓動，將支持回滾一切嗎？如果沒有，即使使用ConnectAndDisconnect，您也可以獲得事務支持。你必須安排，以便確定「高層次」的事務，然後使用例如「TransactionScope的」在C＃代碼（http://msdn.microsoft.com/en-us/library/system.transactions.transactionscope.aspx） – FrenchData 2010-02-23 10:50:56

@法國數據我被描述爲來自業務邏輯層的中層交易。我們已經嘗試了TransactionScope的方法，但它是不夠的，我們很快就遇到了麻煩，因爲中間層的代碼在不同的不可預見的方式使用。解決方案在某種程度上是兩種方法的混合體，我們的ConnectionManager類支持這兩種方法。當然，從應用程序開始就不需要交易，這就是爲什麼混合解決方案更好。 – AureliusMarcus 2010-02-24 11:30:46

多線程和數據庫連接

回答

相關問題