實體框架併發性：事務還是併發修復？

Question

我需要進行庫存控制，所以我需要確保當我修改產品的數量時，正在以正確的方式進行。我使用實體框架4.0

例如，如果我使用了一個交易，當我從數據庫中加載的記錄，該條記錄被阻塞，這樣我就可以。減去或添加到負載量，項目數，我需要。但是，這會阻止數據庫中的記錄，也許出於性能原因不是最好的方式。這讓我問及何時使用與EF的交易。

另一個選擇是使用實體框架的併發固定，使用時間跨度列來檢測記錄是否已更改。在這種情況下，如果記錄已在我的加載和我的更新之間進行了修改，我會遇到併發的異常。但可能會發生的情況是，在我的異常處理程序中，如果使用數據庫數據更新我的上下文，則可能會再次更改我的刷新和保存更改。

其他問題是我終於可以保存更改了。例如，我有10個單位，我需要減去8個，但在我的負荷和我的更新之間，其他人減去5個單位。如果我減去8，那麼庫存我有-3個單位。這不可能。如果我有交易，我加載記錄，被阻止，所以我可以檢查我是否有足夠的單位，如果是，我可以扣除，如果沒有，我發送異常。

所以我的問題是，我知道EF本身是一個事務，但它也存在EF中的事務，所以它在某些情況下會很有用。何時使用EF和cocurrency固定以及何時使用交易？

謝謝。 Daimroc。

Answer 1

事務不應該用來解決併發問題。您應該儘可能縮短事務處理時間，以防止數據庫被阻塞。這裏走的路是樂觀的併發 - 在數據庫（SqlServer）中，您創建了一個rowversion列，每當修改行時都會自動更改。您將其用作併發令牌。在保存更改時，EF會根據實體上的值檢查此值，如果它們不匹配，則會引發異常。 請注意，對於SaveChanges，EF始終創建一個事務，因爲通常您會保存多個實體，並且如果出現問題，數據庫需要恢復到原始狀態 - 否則它將處於損壞狀態。 爲了防止低於零 - 如果使用樂觀併發 - 如果數據庫中的值發生更改，將無法保存，因爲併發標記將不同，因爲行已被修改，因此對客戶端的檢查應該是足夠。或者，您可以將保存實體的映射映射到將在保存之前檢查值的存儲過程，並且如果保存後的值不正確，則會返回錯誤。