Concurrency Conflicts

Two people open the same employee record. Both see a salary of 58,000 and a role of Engineer. One changes the salary and saves. A minute later the other changes the role and saves. What happens to the salary?

It depends on how the second save was built, and that is the uncomfortable part. Because EF Core writes only the columns that differ from its snapshot, two users editing different fields of an entity they both loaded in the same context may not collide at all. That is luck, not a design.

In a web application the entity is usually not loaded when the edit begins. The form posts every field back, the code loads the row and copies the posted values over it, or attaches a new instance and marks it modified. Now every column is written, including the ones this user never touched. The other person's change is gone.

That is a lost update. No exception, nothing unusual in the log, and no way to tell afterwards that it happened.

public class Employee
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
    public string Role { get; set; } = "";
    public decimal AnnualSalary { get; set; }
    public int DepartmentId { get; set; }

    // The concurrency token. The database maintains it; you never assign it.
    [Timestamp]
    public byte[]? RowVersion { get; set; }
}

// The same thing in configuration, which keeps persistence out of the entity:
modelBuilder.Entity<Employee>()
    .Property(e => e.RowVersion)
    .IsRowVersion();

• rowversion is a SQL Server column type whose value changes automatically every time the row is written. The value means nothing on its own; what matters is that it differs after any change.
• The attribute is named Timestamp, which is unhelpful, because the column holds no date or time. IsRowVersion in configuration says the same thing more clearly.
• Other providers have equivalents — PostgreSQL uses its system xmin column — and with any database you can mark an ordinary column as a concurrency token with IsConcurrencyToken and maintain it yourself.
• The token has to travel with the edit. If a web form round-trips the row version in a hidden field, it must be the value read when the form was rendered. Fetching a fresh one at save time defeats the whole mechanism.

-- Priya saves first
UPDATE [Employees] SET [AnnualSalary] = @p0
OUTPUT INSERTED.[RowVersion]
WHERE [Id] = @p1 AND [RowVersion] = @p2;
-- @p2 = 0x00000000000007D1, the value Priya read
-- 1 row updated, and a new RowVersion is returned

-- Sam saves a minute later, carrying the same row version Sam read
UPDATE [Employees] SET [Role] = @p0, [AnnualSalary] = @p1
OUTPUT INSERTED.[RowVersion]
WHERE [Id] = @p2 AND [RowVersion] = @p3;
-- @p3 = 0x00000000000007D1, no longer the current value
-- 0 rows updated

• The token is part of the WHERE clause. The UPDATE applies only if the row still looks the way it did when this user read it.
• Priya's save changed the row, so the database generated a new row version. Sam's WHERE clause now matches nothing.
• Zero rows updated is the signal. EF Core expected one, got none, and throws DbUpdateConcurrencyException instead of reporting success. The lost update has become an error you can handle, which is the whole mechanism.
• This is called optimistic concurrency: no locks are taken while the user thinks, and the conflict is detected at the moment of writing. The alternative, holding a lock from read to write, does not survive a user who goes to lunch with a form open.

// EntityEntry and PropertyValues live in
// Microsoft.EntityFrameworkCore.ChangeTracking.
try
{
    await context.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException ex)
{
    EntityEntry entry = ex.Entries.Single();
    PropertyValues? stored = await entry.GetDatabaseValuesAsync();

    if (stored is null)
    {
        // Somebody deleted the row. There is nothing to merge into.
        throw new InvalidOperationException("That employee no longer exists.");
    }

    // Merge: this user only meant to change the role, so let the stored
    // salary stand and keep the role they typed.
    entry.CurrentValues[nameof(Employee.AnnualSalary)] =
        stored[nameof(Employee.AnnualSalary)];

    // Accept the stored row as the new baseline so the retry passes the check.
    entry.OriginalValues.SetValues(stored);

    await context.SaveChangesAsync();
}

• ex.Entries holds the entities whose save failed. For a single-row edit there is exactly one.
• GetDatabaseValuesAsync re-reads the row as it stands now. A null result means it was deleted rather than changed, which needs its own answer — usually telling the user, because there is nothing left to write to.
• The merge line is the interesting one: the field this user did not intend to change is taken from the database, so the other person's edit survives.
• Setting OriginalValues to the stored values updates the snapshot, including the row version. The second SaveChanges therefore sends a WHERE clause that matches, and it succeeds.
• For store wins, call entry.ReloadAsync() instead and ask the user to try again against the current values. For client wins, set OriginalValues and retry without touching CurrentValues.
• Retry once. If you loop, cap the attempts — a busy row can keep moving underneath you, and an uncapped retry turns a conflict into a hot loop.