最近在園子里看到一篇關(guān)于TransactionScope的文章，發(fā)現(xiàn)事務(wù)和并發(fā)控制是新接觸Entity Framework和Transaction Scope的園友們不易理解的問題，遂組織此文跟大家共同探討。

首先事務(wù)的ACID特性作為最基礎(chǔ)的知識(shí)我想大家都應(yīng)該知道了。ADO.NET的SQLTransaction就是.NET框架下訪問SqlServer時(shí)最底層的數(shù)據(jù)庫事務(wù)對(duì)象，它可以用來將多次的數(shù)據(jù)庫訪問封裝為“原子操作”，也可以通過修改隔離級(jí)別來控制并發(fā)時(shí)的行為。TransactionScope則是為了在分布式數(shù)據(jù)節(jié)點(diǎn)上完成事務(wù)的工具，它經(jīng)常被用在業(yè)務(wù)邏輯層將多個(gè)數(shù)據(jù)庫操作組織成業(yè)務(wù)事務(wù)的場景，可以做到透明的可分布式事務(wù)控制和隱式失敗回滾。但與此同時(shí)也經(jīng)常有人提到TransactionScope有性能和部署方面的問題，關(guān)于這一點(diǎn)，根據(jù)MSDN的 Using the TransactionScope Class 的說法，當(dāng)一個(gè)TransactionScope包含的操作是同一個(gè)數(shù)據(jù)庫連接時(shí)，它的行為與SqlTransaction是類似的。當(dāng)它在多個(gè)數(shù)據(jù)庫連接上進(jìn)行數(shù)據(jù)操作時(shí)，則會(huì)將本地?cái)?shù)據(jù)庫事務(wù)提升為分布式事務(wù)，而這種提升要求各個(gè)節(jié)點(diǎn)均安裝并啟動(dòng)DTC服務(wù)來支持分布式事務(wù)的協(xié)調(diào)工作，它的性能與本地?cái)?shù)據(jù)庫事務(wù)相比會(huì)低很多，這也是CAP定律說的分布式系統(tǒng)的Consistency和Availability不可兼得的典型例子。所以當(dāng)我們選擇是否使用TransactionScope時(shí)，一定要確認(rèn)它會(huì)不會(huì)導(dǎo)致不想發(fā)生的分布式事務(wù)，也應(yīng)該確保事務(wù)盡快做完它該做的事情，為了確認(rèn)事務(wù)是否被提升我們可以用SQL Profiler去跟蹤相關(guān)的事件。

然后再來看一看Entity Framework，其實(shí)EF也跟事務(wù)有關(guān)系。它的Context概念來源于Unit of Work模式，Context記錄提交前的所有Entity變化，并在SaveChanges方法調(diào)用時(shí)發(fā)起真正的數(shù)據(jù)庫操作，SaveChanges方法在默認(rèn)情況下隱含一個(gè)事務(wù)，并且試圖使用樂觀并發(fā)控制來提交數(shù)據(jù)，但是為了進(jìn)行并發(fā)控制我們需要將Entity Property的ConcurrencyMode設(shè)置為Fixed才行，否則EF不理會(huì)在此Entity上面發(fā)生的并發(fā)修改，這一點(diǎn)可以參考MSDN Saving Changes and Managing Concurrency。微軟推薦大家使用以下方法來捕獲沖突的并發(fā)操作，并使用RefreshMode來選擇覆蓋或丟棄失敗的操作：

 1         try
 2         {
 3             // Try to save changes, which may cause a conflict.
 4             int num = context.SaveChanges();
 5             Console.WriteLine("No conflicts. " +
 6                 num.ToString() + " updates saved.");
 7         }
 8         catch (OptimisticConcurrencyException)
 9         {
10             // Resolve the concurrency conflict by refreshing the 
11             // object context before re-saving changes. 
12             context.Refresh(RefreshMode.ClientWins, orders);
13 
14             // Save changes.
15             context.SaveChanges();
16             Console.WriteLine("OptimisticConcurrencyException "
17             + "handled and changes saved");
18         }

當(dāng)然除了樂觀并發(fā)控制我們還可以對(duì)沖突特別頻繁、沖突解決代價(jià)很大的用例進(jìn)行悲觀并發(fā)控制。悲觀并發(fā)基本思想是不讓數(shù)據(jù)被同時(shí)離線修改，也就是像源碼管理里面“加鎖”功能一樣，碼農(nóng)甲鎖上了這個(gè)文件，乙就不能再修改了，這樣一來這個(gè)文件就不可能發(fā)生沖突，悲觀并發(fā)控制實(shí)現(xiàn)的方式比如數(shù)據(jù)行加IsLocked字段等。

最后為了進(jìn)行多Context事務(wù)，當(dāng)然還可以混合使用TransactionScope和EF。

好了理論簡單介紹完，下面的例子是幾種不同的方法對(duì)并發(fā)控制的效果，需求是每個(gè)Member都有個(gè)HasMessage字段，初始為False，我們需要給其中一個(gè)Member加入唯一一條MemberMessage，并將Member.HasMessage置為True。

建庫腳本：

 1 CREATE DATABASE [TransactionTest]
 2 GO
 3 
 4 USE [TransactionTest]
 5 GO
 6 
 7 CREATE TABLE [dbo].[Member](
 8     [Id] [int] IDENTITY(1,1) NOT NULL,
 9     [Name] [nvarchar](32) NOT NULL,
10     [HasMessage] [bit] NOT NULL,
11  CONSTRAINT [PK_Member] PRIMARY KEY CLUSTERED 
12 (
13     [Id] ASC
14 )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
15 ) ON [PRIMARY]
16 GO
17 SET IDENTITY_INSERT [dbo].[Member] ON
18 INSERT [dbo].[Member] ([Id], [Name], [HasMessage]) VALUES (1, N'Tom', 0)
19 INSERT [dbo].[Member] ([Id], [Name], [HasMessage]) VALUES (2, N'Jerry', 0)
20 SET IDENTITY_INSERT [dbo].[Member] OFF
21 
22 CREATE TABLE [dbo].[MemberMessage](
23     [Id] [int] IDENTITY(1,1) NOT NULL,
24     [Message] [nvarchar](128) NOT NULL,
25     [MemberId] [int] NOT NULL,
26  CONSTRAINT [PK_MemberMessage] PRIMARY KEY CLUSTERED 
27 (
28     [Id] ASC
29 )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
30 ) ON [PRIMARY]
31 GO
32 
33 ALTER TABLE [dbo].[MemberMessage]  WITH CHECK ADD  CONSTRAINT [FK_MemberMessage_Member] FOREIGN KEY([MemberId])
34 REFERENCES [dbo].[Member] ([Id])
35 GO
36 ALTER TABLE [dbo].[MemberMessage] CHECK CONSTRAINT [FK_MemberMessage_Member]
37 GO

View Code

方法1：不使用TransactionScope，只依賴Entity各字段的默認(rèn)并發(fā)控制。

Context和Entity定義

 1 public class MyDbContext : DbContext
 2 {
 3     public MyDbContext() : base("TransactionTest") { }
 4 
 5     public MyDbContext(string connectionString) :
 6         base(connectionString)
 7     {
 8 
 9     }
10 
11     public DbSet<Member> Members { get; set; }
12 }
13 
14 [Table("Member")]
15 public class Member
16 {
17     [Key]
18     public int Id { get; set; }
19 
20     public string Name { get; set; }
21 
22     public bool HasMessage { get; set; }
23 
24     public virtual ICollection<MemberMessage> Messages { get; set; }
25 }
26 
27 [Table("MemberMessage")]
28 public class MemberMessage
29 {
30     [Key]
31     public int Id { get; set; }
32 
33     public string Message { get; set; }
34 
35     public int MemberId { get; set; }
36 
37     [ForeignKey("MemberId")]
38     public virtual Member Member { get; set; }
39 }

View Code

測試代碼

 1 try
 2 {
 3     using (var context = new MyDbContext())
 4     {
 5         var tom = context.Members.FirstOrDefault(m => m.Id == 1);
 6         if (tom != null && !tom.HasMessage)
 7         {
 8             Console.WriteLine("Press Enter to Insert MemberMessage...");
 9             Console.ReadLine();
10             tom.Messages.Add(new MemberMessage()
11                                     {
12                                         Message = "Hi Tom!"
13                                     });
14             tom.HasMessage = true;
15             context.SaveChanges();
16             Console.WriteLine("Insert Completed!");
17         }
18     }
19 }
20 catch (Exception ex)
21 {
22     Console.WriteLine("Insert Failed: " + ex);
23 }

View Code

同時(shí)運(yùn)行兩個(gè)程序，結(jié)果是無法確保不重復(fù)插入

通過分析不難發(fā)現(xiàn)，該場景的并發(fā)控制關(guān)鍵就在于插入前檢查HasMessage如果是False，則插入MemberMessage后更新Member.HasMessage字段時(shí)需要再次檢查數(shù)據(jù)庫中HasMessage字段是否為False，如果為True就是有其他人并發(fā)的更改了該字段，本次保存應(yīng)該回滾或做其他處理。所以為此需要有針對(duì)性的加入并發(fā)控制。

方法2：給HasMessage字段加上并發(fā)檢查

 1     [Table("Member")]
 2     public class Member
 3     {
 4         [Key]
 5         public int Id { get; set; }
 6 
 7         public string Name { get; set; }
 8 
 9         [ConcurrencyCheck]
10         public bool HasMessage { get; set; }
11 
12         public virtual ICollection<MemberMessage> Messages { get; set; }
13     }

仍然使用方法1的測試代碼，結(jié)果則是其中一次數(shù)據(jù)插入會(huì)拋出OptimisticConcurrencyException，也就是說防止重復(fù)插入數(shù)據(jù)的目的已經(jīng)達(dá)到了。

那回過頭來看看是否可以使用TransactionScope對(duì)EF進(jìn)行并發(fā)控制，于是有方法3：使用TransactionScope但不給Entity加入并發(fā)檢查

Context和Entity的定義與方法1完全一致，測試代碼為

 1 try
 2 {
 3     using (var scope = new System.Transactions.TransactionScope())
 4     {
 5         using (var context = new MyDbContext())
 6         {
 7             var tom = context.Members.FirstOrDefault(m => m.Id == 1);
 8             if (tom != null && !tom.HasMessage)
 9             {
10                 Console.WriteLine("Press Enter to Insert MemberMessage...");
11                 Console.ReadLine();
12                 tom.Messages.Add(new MemberMessage()
13                                         {
14                                             Message = "Hi Tom!"
15                                         });
16                 tom.HasMessage = true;
17                 context.SaveChanges();
18                 Console.WriteLine("Insert Completed!");
19             }
20         }
21         scope.Complete();
22     }
23 }
24 catch (Exception ex)
25 {
26     Console.WriteLine("Insert Failed: " + ex);
27 }

View Code

同樣啟動(dòng)兩個(gè)程序測試，發(fā)現(xiàn)其中一次保存操作拋出DbUpdateException，其內(nèi)部原因是Transaction死鎖導(dǎo)致該操作被作為犧牲者。所以看起來也可以達(dá)到并發(fā)控制的效果，這種方式的優(yōu)點(diǎn)是不需要去仔細(xì)辨別業(yè)務(wù)中哪些操作會(huì)導(dǎo)致字段的并發(fā)更新沖突，所有的Entity都可以不加ConcurrencyCheck，缺點(diǎn)則是當(dāng)沖突不多的時(shí)候這種死鎖競爭協(xié)調(diào)與樂觀并發(fā)控制相比性能會(huì)低些。

最后為了完備測試各種組合，我們?cè)囈辉?strong>方法4：既使用TransactionScope，又在HasMessage字段上加入ConcurrencyCheck，Entity代碼參考方法1，測試代碼則參考方法3，結(jié)果仍然是TransactionScope檢測到死鎖并選擇其中一個(gè)競爭者拋出異常。

結(jié)論：

1. TransactionScope用或不用主要取決于是否需要進(jìn)行分布式事務(wù)
2. 即使不需要分布式事務(wù)，TransactionScope也可以用于沒有精力仔細(xì)分析哪些Entity的字段需要進(jìn)行并發(fā)檢查的時(shí)候
3. 如果能夠細(xì)粒度分析并發(fā)場景，則推薦使用EF自帶的并發(fā)控制機(jī)制