using System;  using System.Collections.Generic;  using System.Data.Entity;  using System.Data.SqlClient;  using System.Linq;  using System.Transactions;    namespace TransactionsExamples  {      class TransactionsExample      {          static void StartOwnTransactionWithinContext()          {              using (var context = new BloggingContext())              {                  using (var dbContextTransaction = context.Database.BeginTransaction())                  {                      try                      {                          context.Database.ExecuteSqlCommand(                              @"UPDATE Blogs SET Rating = 5" +                                  " WHERE Name LIKE '%Entity Framework%'"                              );                            var query = context.Posts.Where(p => p.Blog.Rating >= 5);                          foreach (var post in query)                          {                              post.Title += "[Cool Blog]";                          }                            context.SaveChanges();                            dbContextTransaction.Commit();                      }                      catch (Exception)                      {                          dbContextTransaction.Rollback();                      }                  }              }          }      }  }

Note: Beginning a transaction requires that the underlying store connection is open. So calling Database.BeginTransaction() will open the connection  if it is not already opened. If DbContextTransaction opened the connection then it will close it when Dispose() is called.

Passing an existing transaction to the context

Sometimes you would like a transaction which is even broader in scope and which includes operations on the same database but outside of EF completely. To accomplish this you must open the connection and start the transaction yourself and then tell EF a) to use the already-opened database connection, and b) to use the existing transaction on that connection.

To do this you must define and use a constructor on your context class which inherits from one of the DbContext constructors which take i) an existing connection parameter and ii) the contextOwnsConnection boolean.

Note: The contextOwnsConnection flag must be set to false when called in this scenario. This is important as it informs Entity Framework that it should not close the connection when it is done with it (e.g. see line 4 below):

using (var conn = new SqlConnection("..."))  {      conn.Open();      using (var context = new BloggingContext(conn, contextOwnsConnection: false))      {      }  }

Furthermore, you must start the transaction yourself (including the IsolationLevel if you want to avoid the default setting) and let the Entity Framework know that there is an existing transaction already started on the connection (see line 33 below).

Then you are free to execute database operations either directly on the SqlConnection itself, or on the DbContext. All such operations are executed within one transaction. You take responsibility for committing or rolling back the transaction and for calling Dispose() on it, as well as for closing and disposing the database connection. E.g.:

using System;  using System.Collections.Generic;  using System.Data.Entity;  using System.Data.SqlClient;  using System.Linq;  sing System.Transactions;    namespace TransactionsExamples  {       class TransactionsExample       {          static void UsingExternalTransaction()          {              using (var conn = new SqlConnection("..."))              {                 conn.Open();                   using (var sqlTxn = conn.BeginTransaction(System.Data.IsolationLevel.Snapshot))                 {                     try                     {                         var sqlCommand = new SqlCommand();                         sqlCommand.Connection = conn;                         sqlCommand.Transaction = sqlTxn;                         sqlCommand.CommandText =                             @"UPDATE Blogs SET Rating = 5" +                              " WHERE Name LIKE '%Entity Framework%'";                         sqlCommand.ExecuteNonQuery();                           using (var context =                            new BloggingContext(conn, contextOwnsConnection: false))                          {                              context.Database.UseTransaction(sqlTxn);                                var query =  context.Posts.Where(p => p.Blog.Rating >= 5);                              foreach (var post in query)                              {                                  post.Title += "[Cool Blog]";                              }                             context.SaveChanges();                          }                            sqlTxn.Commit();                      }                      catch (Exception)                      {                          sqlTxn.Rollback();                      }                  }              }          }      }  }

Notes:

• You can pass null to Database.UseTransaction() to clear Entity Framework’s knowledge of the current transaction. Entity Framework will neither commit nor rollback the existing transaction when you do this, so use with care and only if you’re sure this is what you want to do.
• You will see an exception from Database.UseTransaction() if you pass a transaction:
  • When the Entity Framework already has an existing transaction
  • When Entity Framework is already operating within a TransactionScope
  • Whose connection object is null (i.e. one which has no connection – usually this is a sign that that transaction has already completed)
  • Whose connection object does not match the Entity Framework’s connection.

Using transactions with other features

This section details how the above transactions interact with:

• Connection resiliency
• Asynchronous methods
• TransactionScope transactions

Connection Resiliency

The new Connection Resiliency feature does not work with user-initiated transactions. For details, see Limitations with Retrying Execution Strategies.

Asynchronous Programming

The approach outlined in the previous sections needs no further options or settings to work with the asynchronous query and save methods. But be aware that, depending on what you do within the asynchronous methods, this may result in long-running transactions – which can in turn cause deadlocks or blocking which is bad for the performance of the overall application.

TransactionScope Transactions

Prior to EF6 the recommended way of providing larger scope transactions was to use a TransactionScope object:

using System.Collections.Generic;  using System.Data.Entity;  using System.Data.SqlClient;  using System.Linq;  using System.Transactions;    namespace TransactionsExamples  {      class TransactionsExample      {          static void UsingTransactionScope()          {              using (var scope = new TransactionScope(TransactionScopeOption.Required))              {                  using (var conn = new SqlConnection("..."))                  {                      conn.Open();                        var sqlCommand = new SqlCommand();                      sqlCommand.Connection = conn;                      sqlCommand.CommandText =                          @"UPDATE Blogs SET Rating = 5" +                              " WHERE Name LIKE '%Entity Framework%'";                      sqlCommand.ExecuteNonQuery();                        using (var context =                          new BloggingContext(conn, contextOwnsConnection: false))                      {                          var query = context.Posts.Where(p => p.Blog.Rating > 5);                          foreach (var post in query)                          {                              post.Title += "[Cool Blog]";                          }                          context.SaveChanges();                      }                  }                    scope.Complete();              }          }      }  }

The SqlConnection and Entity Framework would both use the ambient TransactionScope transaction and hence be committed together.

Starting with .NET 4.5.1 TransactionScope has been updated to also work with asynchronous methods via the use of the TransactionScopeAsyncFlowOption enumeration:

using System.Collections.Generic;  using System.Data.Entity;  using System.Data.SqlClient;  using System.Linq;  using System.Transactions;    namespace TransactionsExamples  {      class TransactionsExample      {          public static void AsyncTransactionScope()          {              using (var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))              {                  using (var conn = new SqlConnection("..."))                  {                      await conn.OpenAsync();                        var sqlCommand = new SqlCommand();                      sqlCommand.Connection = conn;                      sqlCommand.CommandText =                          @"UPDATE Blogs SET Rating = 5" +                              " WHERE Name LIKE '%Entity Framework%'";                      await sqlCommand.ExecuteNonQueryAsync();                        using (var context = new BloggingContext(conn, contextOwnsConnection: false))                      {                          var query = context.Posts.Where(p => p.Blog.Rating > 5);                          foreach (var post in query)                          {                              post.Title += "[Cool Blog]";                          }                            await context.SaveChangesAsync();                      }                  }              }          }      }  }

There are still some limitations to the TransactionScope approach:

• Requires .NET 4.5.1 or greater to work with asynchronous methods.
• It cannot be used in cloud scenarios unless you are sure you have one and only one connection (cloud scenarios do not support distributed transactions).
• It cannot be combined with the Database.UseTransaction() approach of the previous sections.
• It will throw exceptions if you issue any DDL (e.g. because of a Database Initializer) and have not enabled distributed transactions through the MSDTC Service.

Advantages of the TransactionScope approach:

• It will automatically upgrade a local transaction to a distributed transaction if you make more than one connection to a given database or combine a connection to one database with a connection to a different database within the same transaction (note: you must have the MSDTC service configured to allow distributed transactions for this to work).
• Ease of coding. If you prefer the transaction to be ambient and dealt with implicitly in the background rather than explicitly under you control then the TransactionScope approach may suit you better.

In summary, with the new Database.BeginTransaction() and Database.UseTransaction() APIs above, the TransactionScope approach is no longer necessary for most users. If you do continue to use TransactionScope then be aware of the above limitations. We recommend using the approach outlined in the previous sections instead where possible.