laptop
Brand =
Lenovo ThinkPad
laptop
Type = laptop
Type &
A
Submit
st object context
objContext
SaveChanges()
Try
Submit
nd object context and cause cuncurrency exception
objContext
SaveChanges()
Catch ex As OptimisticConcurrencyException
Using refresh method to
objContext
Refresh(Objects
RefreshMode
StoreWins
laptop
)
We should load the new data from db and ask user to change it again
objContext
SaveChanges()
End Try
我們創建了兩個Object Context分別查詢出了同一個實體第一個修改其品牌為Lenovo ThinkPad第二個同時將其型號修改為T A然後第一個實體保存然後第二個保存由於我們在Brand屬性上設置了Concurrency Mode為Fixed而此時laptop中的Brand屬性的值應該是一開始取得的T而數據庫裡的值是Lenovo T於是系統就會拋出OptimisticConcurrencyException(開放式並發異常)當程序捕獲到異常以後就可以使用Object Context的Refresh方法對異常采取處理由於沒有在刷新laptop以後未對其作任何修改故最終結果將與laptop提交時的結果一致
這裡Refresh的第一個參數值得注意一下它是一個枚舉值有兩個選項StoreWins或者是ClientWins見名知義如果是StoreWins那麼Refresh以後laptop的值將與數據庫裡的對應記錄的值一致(修改會丟失)而如果ClientWins則laptop的值保持並且提交以後會把objContext提交的修改覆蓋
其實這兩種方法均不完美總會導致一部分修改丟失但是這總比在不知情的情況下的覆蓋要好
另外需要說明上面的方法只是對並發沖突的一種模擬這樣的模式在處理並發沖突時會有問題一般的處理方法是當檢測到並發沖突時提示用戶會重新從數據庫載入數據然後讓用戶在新數據的情況下重新修改後再次提交直到不再有並發沖突發生
這樣看似可能成為一個無窮盡的痛苦的過程但實際上由於這種處理方式是基於對並發沖突的樂觀估計來設計的因此當我們認為並發沖突很少有可能發生時這種處理方式可以有效避免數據被無意識的覆蓋問題
五示例代碼下載
點擊下載
http://filescnblogscom/xiaomi/Concurrencyzip
[] [] [] []
From:http://tw.wingwit.com/Article/program/net/201311/14740.html