Linq-to-sql上下文數據庫連接處理

Question

linq-to-sql數據上下文如何保持數據庫連接打開的規則是什么？

問題來了，當我們對一個做對性能有一些測試SubmitChanges()每更新的實體，而不是一個SubmitChanges()為單位的整批。 結果：

在一個SubmitChanges（）調用中插入3000個項目...時長：1318ms

在transactionscope內的一個SubmitChanges（）調用中插入3000個項目...時長：1280ms

在單個SubmitChanges（）調用中插入3000個項目...時長：4377ms

在事務中的各個SubmitChanges（）調用中插入3000個項目...時長：2901ms

請注意，當對每個更改的實體進行單獨的SubmitChanges() ，將所有內容放入事務中都可以提高性能，這對我們來說是非常意外的。 在sql server profiler中，我們可以看到事務中的各個SubmitChanges()調用不會重置每個調用的數據庫連接，這與沒有事務的調用相反。

在什么情況下，數據上下文會使連接保持打開狀態？ 是否有任何有關linq-to-sql如何處理連接的詳細文檔？

Answer 1

您沒有顯示整個圖片； 默認情況下，LINQ-to-SQL將對對SubmitChanges的調用包裝在事務中。 如果用另一個事務包裝它，則不會看到連接重置； 直到所有的SubmitChanges調用都已完成，然后提交了外部事務之后，它才能執行。

Answer 2

除了打開/關閉連接時，可能還有許多因素會影響時序。

編輯：在意識到linq2sql如何分別管理緩存的實體和臟實體之后，我刪除了有關跟蹤實體的內容。

您可以通過使用Reflector或其他反匯編程序檢查SqlConnectionManager類上的方法來很好地了解如何在后台管理連接。 如果將提交包裝在自己的事務中，則SubmitChanges將在提交之后在其IProvider（通常為SqlProvider，然后使用SqlConnectionManager）上對其ClearConnection進行調用，但如果SubmitChanges是較大事務的一部分，則不會調用。 打開和關閉連接的時間取決於是否有其他活動使用SqlConnectionManager。

Answer 3

最近我也弄混了。 調用SubmitChanges 3000次不是一個好主意，但是根據插入每個記錄的關鍵程度，您可能要這樣做，畢竟只需要1000毫秒。

我希望看到交易范圍和多個SubmitChanges 。 由於您仍在一次事務中，因此我希望SQL Server能夠更好地處理這一點，這看起來似乎不錯。 一個SubmitChanges並使用顯式/隱式TransactionScope似乎會產生相同的結果，這是可以預期的。 那里應該不存在任何/大部分性能差異。

我認為連接是在需要時創建的，但是您必須記住，連接將在提供程序中進行合並，因此，除非您的連接字符串發生更改，否則您應該掛接到同一個連接池，無論采用哪種方法，它都將產生相同的性能。 由於LINQ-SQL在后台使用SqlConnection ，因此有關它的一些信息如下：

http://msdn.microsoft.com/zh-CN/library/8xx3tyca(VS.80).aspx

如果您的表現強力，可以考慮使用顯式TransactionScope進入存儲過程進行插入。 如果那還不夠快，請考慮使用SqlBulkCopy 。 3000行應比1000ms快。

Answer 4

您是否嘗試過自己打開和關閉連接： 強制打開DataContext的連接（LINQ）

我認為在這種情況下，您不需要額外的交易。