LINQ TO SQL分布式事務(wù)
在向大家詳細(xì)介紹LINQ TO SQL分布式事務(wù)之前，首先讓大家了解下隱式事務(wù)和顯式事務(wù)，然后全面介紹LINQ TO SQL分布式事務(wù)。
LINQ TO SQL，顧名思義，涉及到了數(shù)據(jù)庫操作。那么就會(huì)有一個(gè)事務(wù)的概念，例如，假設(shè)我們需要一次性插入兩個(gè)實(shí)體，但希望保證這兩個(gè)操作的完整性的話。
1. 隱式事務(wù)
其實(shí)，即便我們不寫代碼，LINQ TO SQL也會(huì)自動(dòng)創(chuàng)建一個(gè)事務(wù)的。默認(rèn)事務(wù)隔離級別為ReadCommitted
2. 顯式事務(wù)
我們也可以自己寫代碼，來明確地控制事務(wù)，默認(rèn)事務(wù)隔離級別為ReadCommitted
3. LINQ TO SQL分布式事務(wù)
我們也可以使用TransactionScope對象，來定義LINQ TO SQL分布式事務(wù)。
注意：TransactionScope的默認(rèn)隔離級別為可串行化，可能帶來并發(fā)鎖沖突問題。
***大概要談一下并發(fā)控制的問題：這個(gè)問題的出現(xiàn)就在于，某些時(shí)候，某個(gè)客戶端讀取到了數(shù)據(jù)，然后它斷開了，在本地修改；同時(shí)，另外一個(gè)客戶端也讀取到了數(shù)據(jù)，并且修改并提交了。此時(shí)，***個(gè)客戶端如果再進(jìn)行更新，就應(yīng)該是有所問題的。這就是所謂的并發(fā)問題。
LINQ TO SQL通過在submitchanges方法的時(shí)候指定ConflictMode來定義并發(fā)控制行為：
◆FailOnFirstConflict（默認(rèn)的）
◆ContinueOnConflict
下面有一個(gè)例子，講解了并發(fā)沖突時(shí)繼續(xù)操作，并且對沖突項(xiàng)進(jìn)行解決
- var query = from p in ctx.Products where p.CategoryID == 1 select p;
- foreach (var p in query)
- p.UnitsInStock = Convert.ToInt16(p.UnitsInStock - 1);
- try
- {
- ctx.SubmitChanges(ConflictMode.ContinueOnConflict);
- }
- catch (ChangeConflictException)
- {
- foreach (ObjectChangeConflict cc in ctx.ChangeConflicts)
- {
- Product p = (Product)cc.Object;
- Reponse.Write(p.ProductID + "
- ");
- cc.Resolve(RefreshMode.OverwriteCurrentValues);
- // 放棄當(dāng)前更新，所有更新以原先更新為準(zhǔn)
- }
- }
【編輯推薦】
