放任不管方式
與其說這是一種處理並發沖突的方式
不如說
它是一種沒有對並發沖突做任何處理的方式
但是在許多過去的系統裡
由於沒有考慮到多用戶
網絡應用等情況
這種
處理方式
還真存在於不少系統中
舉例來說
A
B兩人從數據庫中獲取了同一個筆記本的信息
例如
IBM ThinkPad T
吧
然後
A把牌子改成了
Lenovo ThinkPad
B把型號改成了T
A
然後
他們開始提交了
此時
如果A先提交
然後B提交
那麼
最後的結果是
IBM ThinkPad T
A
反之
則變成Lenovo ThinkPad T
總之一句話
誰最後提交誰老大
想像一下
如果A修改了
個屬性的值
B修改了
個屬性的值
那麼
對於先提交的A來說
這將是一個多麼慘痛的打擊:
)
雖然這種放任不管的方式似乎不太負責任
但是
其處理性能卻是相對較高的
開放式並發處理
開放式並發處理
老外叫做Optimistic Concurrency——樂觀的並發
這種並發處理方式要求我們對並發抱有一種樂觀的態度
百分之九十九點九九不會發生並發沖突
萬一發生了
系統也能捕獲到沖突
或者根據策略自動處理
或者
就提醒一下用戶
讓用戶來決定是不是要繼續提交
仍然用上面的例子來說這事兒
A
B兩個人同時獲取了筆記本的信息
IBM ThinkPad T
然後……（此處跟上例做一樣的修改
直到提交）此時
如果A先提交
那麼
B提交的時候
系統會發現
哎喲
不好
有並發沖突了
就會拋個異常給B
讓B知道
發生並發沖突了
然後
B就可以根據實際情況
選擇相應的處理策略（比如
繼續提交進行覆蓋或者取消提交等等）
相反
如果B先提交
那麼
A提交時
就會得到相應的提醒
這樣的並發處理方式
可以說在可靠性與性能上取得平衡
適合於對數據可靠性要求不是特別嚴格
需要較高的性能
並且不會大量發生並發的場合
保守式並發處理
這是最為嚴謹的一種並發沖突的處理方式
它把並發轉化為了串行操作
例如
A從數據庫中獲取了筆記本信息
IBM ThinkPad T
B也要對其進行修改
但此時由於A已經從數據庫中將數據取出
因此
B被置於等待狀態
直到A把數據修改完提交了
數據庫數據更新為Lenovo ThinkPad T
了
此時
數據庫才把數據給B
那麼B就可以在Lenovo ThinkPad T
的基礎上
把它修改為Lenovo ThinkPad T
A
而在B提交前
其它一切針對此記錄的操作都得排除等著B
這樣子當然非常理想
由於不存在並發
自然也就消除了並發沖突的問題
但是
這種鎖也存在著較為隱蔽的風險
如果A修改了數據
一直不提交
或者A因為故障
沒有辦法提交
那麼
其它所有的相關的操作
都將被阻礙住
因此
只有對數據准確性要求極高並且用戶可以忍受等待的情況下
使用這種並發沖突的處理方法
四EF並發沖突處理實例
EF發布時提供了兩種並發沖突處理方式放任不管方式和開放式並發默認采用放任不管的方式處理
如果要使用開放式並發那麼必須設置相應屬性上的Concurrency Mode值為Fixed我們先對實體類的屬性進行修改讓其支持開放式並發然後來模擬一個並發的序列看看怎麼來處理並發沖突
[] [] [] []
From:http://tw.wingwit.com/Article/program/net/201311/14741.html
