我得到以下sql異常: 交易鎖定資源與另一個進程死鎖,並被選爲死鎖犧牲品。重新運行交易。在批次結束時檢測到不可提交的事務。事務回滾。 我沒有任何存儲過程中的任何交易,我從.net進行交易,我總是使用它們來調用它們。 你們以前遇到過嗎?交易已死鎖
Q
交易已死鎖
2
A
回答
3
交易是一個交易,不管從哪裏開始。無論是在C#或RDBMS。
您的using
問題BEGIN TRANSCATION有效。
MSDN (for SQL Server 2000 but still valid)建議您在檢測到死鎖時自動重試,而不是在此處編寫代碼,Google上有許多結果供您閱讀。
0
使用事務時,您需要小心,因爲默認情況下它將隔離級別設置爲可串行化。當連接釋放回池中時,它仍然具有該級別設置。這可能嚴重損害併發性。
相關問題
- 1. 交易 - 如何避免死鎖?
- 2. 在InnoDB死鎖後重復交易
- 3. 交易(進程ID 56)鎖定時死鎖?
- 4. 交易 - 讀鎖
- 5. 交易和鎖
- 6. PHP鎖定交易
- 7. neo4j鎖定交易
- 8. 死鎖在單臺無交易(?)上更新或插入語句
- 9. Laravel究竟是如何處理交易死鎖的?
- 10. 「死鎖受害者」在交易中,如何改變優先權?
- 11. 嘗試鎖定時發現死鎖;嘗試重新啓動交易
- 12. 交易已中止
- 13. 這個BlockingQueue是否容易死鎖?
- 14. 交易,鎖,隔離級別
- 15. 交易鎖定SQL Server 2005
- 16. 交易鎖的替代
- 17. .Net交易鎖問題
- 18. Rails 3 - 交易和鎖定
- 19. 交易中的Postgres鎖
- 20. 交易和鎖定MySQL
- 21. sql lite交易鎖定
- 22. MYSQL X鎖與交易
- 23. 鎖表直到交易提交
- 24. PayPal交易已過期
- 25. Postgresql鎖死鎖
- 26. 如何判斷是否有可能在交易中看到死鎖?
- 27. 死鎖
- 28. 提交失敗:已鎖定
- 29. PHP和pgbouncer處於交易模式:當前交易已中止
- 30. 在死鎖後重新提交事務
海事組織MSDN在這方面顯然是錯誤的。如果你只是在沒有任何想法的情況下自動重試,你很可能會覆蓋別人的變化,也就是說,失去了變化。 – 2011-01-07 19:41:58