Partager via

SaveChanges(false)

  • Article

Most of the time the Entity Framework (EF) can manage transactions for you.

Every time you Add an Entity, Delete an Entity, Change an Entity, Create a Relationship or Delete a Relationship in your .NET code, these changes are remembered by the EF, and when you call SaveChanges()these are converted to appropriate native SQL commands and executed in the database in a transaction.

Sometimes however you want to use your own transaction. Situations where this is useful include:

  • Working with an object context and attempting to put a message in a message queue within the same transaction.
  • Working with two object contexts simultaneously.
  • Etc etc etc… You get the idea.

In these situations you want the EF to use an ambient transaction (TransactionScope) but more importantly if something goes wrong outside of the EF, you want to be able to recover.

If you call SaveChanges() or SaveChanges(true),the EF simply assumes that if its work completes okay, everything is okay, so it will discard the changes it has been tracking, and wait for new changes.

Unfortunately though if something goes wrong somewhere else in the transaction, because the EF discarded the changes it was tracking, we can’t recover.

This is where SaveChanges(false) and AcceptAllChanges() come in.

SaveChanges(false) tells the EF to execute the necessary database commands, but hold on to the changes, so they can be replayed if necessary.

Now if the broader transaction fails you can retry the EF specific bits, with another call to SaveChanges(false). Alternatively you can walk through the state-manager to log what failed.

Once the broader transaction succeeds, you simply call AcceptAllChanges() manually, and the changes that were being tracked are discarded.

Typically pseudo-code for this is something like this…

using (TransactionScope scope = new TransactionScope())
{
    //Do something with context1
    //Do something with context2

    //Save Changes but don't discard yet
    context1.SaveChanges(false);

    //Save Changes but don't discard yet
    context2.SaveChanges(false);

    //if we get here things are looking good.
    scope.Complete();

    //If we get here it is save to accept all changes.
    context1.AcceptAllChanges();
    context2.AcceptAllChanges();

}

If you fall out of the using block because of an exception you can now potentially retry.

Make sense?

Comments

  • Anonymous
    February 08, 2010
    Hi,Thanks for you comprehensive article on SaveChanges(False) article. I would like to know why we can't call to both context1.AceptAllChanges() and context2.AceptAllChanges() directly and then followed by the scope.Complete(). Since we are already in the transactionscope, then the transactionscope should do all the transaction for us instead of having us to take care of it.ThanksRegardsdavid
  • Anonymous
    February 08, 2010
    The comment has been removed
  • Anonymous
    March 17, 2010
    The comment has been removed
  • Anonymous
    March 27, 2010
    I wonder in your article:is it possible to use two context instances for the same Object Context Class?
  • Anonymous
    October 20, 2010
    the problem is that it doesnt work... it throws an error on context2.SaveChanges(false). the error message says: underlying connection is closed
  • Anonymous
    May 20, 2012
    And for using SaveChanges(false) in EF4 look here:stackoverflow.com/.../entity-framework-transactions-replacing-savechangesbool-with-savechangessav