LINQ TO SQL分布式事務(wù)舉例分析

本篇內(nèi)容介紹了“LINQ TO SQL分布式事務(wù)舉例分析”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

LINQ TO SQL，顧名思義，涉及到了數(shù)據(jù)庫(kù)操作。那么就會(huì)有一個(gè)事務(wù)的概念，例如，假設(shè)我們需要一次性插入兩個(gè)實(shí)體，但希望保證這兩個(gè)操作的完整性的話(huà)。

1. 隱式事務(wù)

其實(shí)，即便我們不寫(xiě)代碼，LINQ TO SQL也會(huì)自動(dòng)創(chuàng)建一個(gè)事務(wù)的。默認(rèn)事務(wù)隔離級(jí)別為ReadCommitted

2. 顯式事務(wù)

我們也可以自己寫(xiě)代碼，來(lái)明確地控制事務(wù)，默認(rèn)事務(wù)隔離級(jí)別為ReadCommitted

3. LINQ TO SQL分布式事務(wù)

我們也可以使用TransactionScope對(duì)象，來(lái)定義LINQ TO SQL分布式事務(wù)。

注意：TransactionScope的默認(rèn)隔離級(jí)別為可串行化，可能帶來(lái)并發(fā)鎖沖突問(wèn)題。

***大概要談一下并發(fā)控制的問(wèn)題：這個(gè)問(wèn)題的出現(xiàn)就在于，某些時(shí)候，某個(gè)客戶(hù)端讀取到了數(shù)據(jù)，然后它斷開(kāi)了，在本地修改；同時(shí)，另外一個(gè)客戶(hù)端也讀取到了數(shù)據(jù)，并且修改并提交了。此時(shí)，***個(gè)客戶(hù)端如果再進(jìn)行更新，就應(yīng)該是有所問(wèn)題的。這就是所謂的并發(fā)問(wèn)題。

LINQ TO SQL通過(guò)在submitchanges方法的時(shí)候指定ConflictMode來(lái)定義并發(fā)控制行為：
◆FailOnFirstConflict（默認(rèn)的）
◆ContinueOnConflict

下面有一個(gè)例子，講解了并發(fā)沖突時(shí)繼續(xù)操作，并且對(duì)沖突項(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)  }  }

“LINQ TO SQL分布式事務(wù)舉例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！