entityframework与transactionscope事务和并发控制.docxVIP

EntityFramework 与 TransactionScope 事务和并发控制 EntityFramework 与 TransactionScope 事务和并发控制 最近在园子里看到一篇关于 TransactionScope 的文章，发现 事务和并发控制是新接触 Entity Framework 和 Transaction Scope的园友们不易理解的问题，遂组织此文跟大家共同探 讨。 首先事务的 ACID 特性作为最基础的知识我想大家都应该知 道了。 ADO.NET 的 SQLTransaction 就是 .NET 框架下访问 SqlServer 时最底层的数据库事务对象， 它可以用来将多次的 数据库访问封装为“原子操作” ，也可以通过修改隔离级别 来控制并发时的行为。 TransactionScope 则是为了在分布式数 据节点上完成事务的工具，它经常被用在业务逻辑层将多个 数据库操作组织成业务事务的场景，可以做到透明的可分布 式事务控制和隐式失败回滚。但与此同时也经常有人提到 TransactionScope 有性能和部署方面的问题， 关于这一点， 根 据 MSDN 的 Using the TransactionScope Class 的说法，当一 个 TransactionScope 包含的操作是同一个数据库连接时，它 的行为与 SqlTransaction 是类似的。当它在多个数据库连接 上进行数据操作时，则会将本地数据库事务提升为分布式事 务，而这种提升要求各个节点均安装并启动 DTC 服务来支 持分布式事务的协调工作，它的性能与本地数据库事务相比 会低很多，这也是 CAP 定律说的分布式系统的 Consistency 和 Availability 不可兼得的典型例子。 所以当我们选择是否使 用 TransactionScope 时，一定要确认它会不会导致不想发生 的分布式事务，也应该确保事务尽快做完它该做的事情，为 了确认事务是否被提升我们可以用 SQL Profiler 去跟踪相关 的事件。 然后再来看一看 Entity Framework ，其实 EF 也跟事务有关系。 它的 Context 概念来源于 Unit of Work 模式， Context 记录提 交前的所有 Entity 变化，并在 SaveChanges 方法调用时发起 真正的数据库操作， SaveChanges 方法在默认情况下隐含一 个事务，并且试图使用乐观并发控制来提交数据，但是为了 进行并发控制我们需要将 Entity Property 的 ConcurrencyMode 设置为 Fixed 才行，否则 EF 不理会在此 Entity 上面发生的并发修改，这一点可以参考 MSDN Saving Changes and Managing Concurrency。微软推荐大家使用以下 方法来捕获冲突的并发操作，并使用 RefreshMode 来选择覆 盖或丢弃失败的操作： try { // Try to save changes, which may cause a conflict. 10Console.WriteLine(No conflicts. +num.ToString() + updates saved.);catch (OptimisticConcurrencyException)// Resolve the concurrency conflict byrefreshing the11// object context before re-saving changes.12context.Refresh(RefreshMode.ClientWins,orders); 10 Console.WriteLine(No conflicts. + num.ToString() + updates saved.); catch (OptimisticConcurrencyException) // 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 17Console.WriteLine(OptimisticConcurrencyException 17 + handled and changes saved); 18 当然除了乐观并发控制我们还可以对冲突特别频繁、冲突解