我們一直在使用一種機制（稱爲SqlDeadlockHelper的類）已經有一段時間了，並且在由於死鎖而嘗試失敗的數據庫調用時幫助了我們很多。 SqlDeadlockHelper將捕獲SqlException，認識到它是一個僵局，然後再試一次。第二次嘗試幾乎總是成功。重試命令/連接超時安全嗎？
對命令和/或連接超時執行類似操作是否安全？我的意思是，在SQL Server上完成工作是不可能的，只能在數據回到調用者之前超時，是嗎？
編輯：
交易已提到的方式來對待來電作爲一個工作單元。這樣它可以成功或完全回滾。但是單個ADO.NET調用只能做一件事。是否有必要在交易中包裝？
檢測到死鎖後，數據庫引擎通過結束選擇 線程作爲死鎖犧牲品的一個僵局。數據庫引擎 終止正在爲該線程執行的當前批處理，回滾死鎖受害者的事務 ，並將該錯誤返回給應用程序的 。爲死鎖受害者回滾事務 將釋放事務持有的所有鎖定。這允許其他線程的事務處於解除阻塞狀態並繼續。 1205死鎖受害者錯誤記錄有關線程 和錯誤日誌中死鎖涉及的資源的信息。
因此，您的交易安全地回滾，您可以再試一次。
編輯
作爲一個懶** E，我還沒有仔細閱讀你的問題。 讓我們看看：
對命令和/或連接超時執行類似操作是否安全？
我不會做同樣的泛化，因爲你可能最終試圖從數據庫中讀取根本無法訪問的數據。您應該有最大數量的重試次數。
我的意思是，它是不可能得到的數據之前返回給調用者，是工作，完成SQL Server上，才 超時？
從未聽說過這一點，如果您使用交易則不應該有可能。並且您應該使用它們以及XACT_ABORT，即Specifies whether SQL Server automatically rolls back the current transaction when a Transact-SQL statement raises a run-time error.的標誌。但是，工作既不能完成也不可能完成 - 請參閱zombie transaction。
這是一個僵局。我在問超時時間。 –
：D對不起，這很愚蠢：P – OzrenTkalcecKrznaric
謝謝。看我的編輯。我問，因爲我們有一個現有的應用程序與許多單個ADO.NET調用到處都是。我需要知道是否有必要將所有這些包含在交易中。 –
根據您的工作單元，SQL有可能在死鎖和拋出錯誤之前完成部分工作。處理工作單位的方式是交易。大多數SQL數據庫支持事務。您需要將工作單元包裝在開始，提交和回滾事務中。
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqltransaction.aspx
所以這也應該適用於超時？關鍵是要使用交易。如果交易失敗，可以再試一次。如果它不在交易中，它只是一個直接的ADO.NET調用？可以重試嗎？ –
這是正確的，它適用於所有SQL命令。如果這些命令不在交易中，那麼您不能保證是「單一」工作單位，這可能會導致部分數據提交。事務是一個SQL概念，是爲了處理您遇到的情況以及其他情況而創建的。這裏有一個使用ADO事務的例子。 http://msdn.microsoft.com/en-us/library/aa227162(v=VS.60).aspx –
謝謝，約翰。對我的編輯有任何評論？ –
我不明白爲什麼不...... –