并发访问实体框架中的记录

Question

I am working on finding an elegant solution to handle concurrency conflict in Entity Framework.

My table for administered drugs has a few columns like drug name, dose, frequency, administer method, notes and few more. An operator can modify fields like dose, frequency, administer method etc after reviewing records OR they can just add notes.

SQL Server database is being used by us.

I have added a column LastUpdated of type timestamp . I'm using this column to raise DbUpdateConcurrencyException . The ConcurrencyMode for the LastUpdated column has been set to Fixed in the entity designer.

The code snippet from my controller class :

// drugId and strNotes are passed from edit screen
DataAccessLayer.Dal dal= new DataAccessLayer.Dal();

// Select record
DrugDetail drugDetail = (from drugRow in dal.DrugDetails
                         where drugRow.id == drugId
                         select drugRow).ToList<DrugDetail>()[0];

// Assign notes 
drugDetail.Notes = strNotes;

try
{
    dal.SaveChanges();
}
catch(DbUpdateConcurrencyException ex)
{
    ((IObjectContextAdapter)dal).ObjectContext.
             Refresh(System.Data.Objects.RefreshMode.StoreWins, drugDetail);

    // Set the notes data again
    drugDetail.Notes = strNotes;

    // Is it possible that DbUpdateConcurrencyException occur again here
    dal.SaveChanges();
}

I'm worried that concurrency conflict can again occur when SaveChanges() is called from catch block. I think it is possible that another user can modify and save the same record between refresh and save in catch block.

Is my worried valid? I could not find any concrete answer by searching on net.

I was thinking to create this scenario in my test environment and verify behavior but then thought to check in forum here first.

Thanks for help.

As requested DrugDetail class is added here:

public partial class DrugDetail
{
    public long id { get; set; }
    public string DrugName { get; set; }
    public Nullable<decimal> Dose { get; set; }
    public Nullable<byte> Frequency { get; set; }
    public string Method { get; set; }
    public string Notes { get; set; }
    public byte[] LastUpdated { get; set; }
}

Answer 1

Concurrency conflict may occur at any time.

Use a loop to repeat the process until you can save the changes without a concurrency conflict.

DataAccessLayer.Dal dal= new DataAccessLayer.Dal();

//Select record
DrugDetail drugDetail = (from drugRow in dal.DrugDetails
                         where drugRow.id == drugId
                         select drugRow).Single();

int count = 0;

while ( true )
{
    //Assign notes 
    drugDetail.Notes = strNotes;

    try
    {
        dal.SaveChanges();
        break;
    }
    catch(DbUpdateConcurrencyException)
    {
        count++;
        if ( count > 10 )
          throw;

        ((IObjectContextAdapter)dal).ObjectContext.
                 Refresh(System.Data.Objects.RefreshMode.StoreWins, drugDetail);

    }
}

Answer 2

It sounds like you are attempting to homegrow your own optimistic concurrency mechanism. This probably won't work so well because there is always a chance the data has changed, even in the tiny instant between when you call SaveChanges and when SQL Server writes the data to the table, while the bits are still going over the wire.

You need special setup in order to make this work correctly. If you are using the Entity Framework, you need to set up the LastUpdated column as the concurrency token, with something like this:

modelBuilder.Entity<Department>().Property(p => p.LastUpdated).IsConcurrencyToken();

Then you'd need to handle any DbUpdateConcurrencyException thrown during the save operation.

bool saveFailed; 
do 
{ 
    saveFailed = false; 
    try 
    { 
        context.SaveChanges(); 
    } 
    catch (DbUpdateConcurrencyException ex) 
    { 
        saveFailed = true; 

        // Get the current entity values and the values in the database 
        var entry = ex.Entries.Single(); 
        var currentValues = entry.CurrentValues; 
        var databaseValues = entry.GetDatabaseValues(); 

        // Choose an initial set of resolved values. In this case we 
        // make the default be the values currently in the database. 
        var resolvedValues = databaseValues.Clone(); 

        // Have the user choose what the resolved values should be 
        HaveUserResolveConcurrency(currentValues, databaseValues, resolvedValues); 

        // Update the original values with the database values and 
        // the current values with whatever the user choose. 
        entry.OriginalValues.SetValues(databaseValues); 
        entry.CurrentValues.SetValues(resolvedValues); 
    } 
} while (saveFailed); 

Doing it this way allows the EF to construct the SQL in such a way that the time stamp is checked and the data are updated within the same, atomic transaction.

If you insist on doing it yourself, you could wrap the read and the save in a transaction of your own (be sure to choose an appropriate transaction isolation level ). However this would be far less efficient and lengthen the time that the row/page/table is locked, which will hurt performance if you have a lot of users.

More information can be found here .