Question

这是一个引用“因此，如果您只使用一个对象上下文，那么在使用ObjectContext.SaveChanges方法时，您已经内置了对数据库事务的支持。”我在这里找到了http://www.luisrocha.net/2011/08/managing-transactions-with-entity.html

因此，根据这一点，我不必在下面的代码中使用TransactionScope，对吗？

if (isLastCallSuccess)
 {
   if (condition1) //it's clear, no transaction needed
    {
      product.Property1 = true;
      context.SaveChanges();
    }

    else if (condition2)
     {
      using (TransactionScope scope = new TransactionScope()) //do I need it?
      {
        context.DeleteObject(item);             //deleting
        context.AddObject("product", new product      //adding
                                {
                                    Id = oldObject.Id,
                                    Property1 = true
                                });
        context.SaveChanges(System.Data.Objects.SaveOptions.DetectChangesBeforeSave);
                                scope.Complete();
        context.AcceptAllChanges();

        }
      }

Answer 1

我个人会保留TransactionScope所以所有内容都作为一个整体提交或者在出错时回滚（即你的保存或添加失败）。如果并发是应用程序的主要部分，使用它将使您的用户受益，确保数据的完整性是一致的。

Answer 2

我不同意;因为您对数据有多个操作，并且您希望确保操作完全成功或完全失败（原子）。确保你是原子的也是一种好习惯。

如果您的删除工作正常，但您的添加失败，则会使数据库处于错误状态。至少如果你有一个事务，数据库将在你尝试第一次操作之前回到原始状态。

编辑：

只是为了完成，在一个事务中，当你开始在同一个方法/进程中操作多个表时，能够在任何时候回滚事务是至关重要的。

Answer 3

引用的含义是对SaveChanges的单个调用会自动包含在事务中，因此它是原子的。但是，您多次调用SaveChanges，因此为了使较大的操作成为原子操作，您需要使用当前拥有的事务。

是的，你需要它。

Answer 4

我相信您的方案确实需要使用交易。 SaveChanges创建一个隐式事务，这样当它继续对任何对象进行更改并且该更改无法持久化时，它将回滚它尝试进行的所有其他更改。但是SaveChanges创建的事务只与呼叫本身一样长。如果你正在调用SaveChanges两次并希望第一次调用的操作在第二次调用失败时回滚，那么是的，你需要一个包装两个调用的事务，你发布的代码就是这样。

Answer 5

从我如何阅读它，你担心删除和添加不提交到数据库，如果有失败然后滚动事务。我不认为你需要在事务中包装你的插入和删除，因为如上所述，它发生在一个savechanges（）上，它隐含地具有事务管理。所以如果它失败了，那么更改就会被回滚。

在我的情况下是否应该使用交易？

5 个答案: