How EF Detects Lost Updates and Builds Concurrency-Sensitive UPDATE/DELETE Predicates

Learning outcomes

The phrase “EF detected a conflict” can sound magical until the generated SQL is inspected. In reality, a tracked update is a conditional write: the primary key identifies the row and the original concurrency token proves that the row still represents the version that was read.

1. A normal tracked UPDATE is a compare-and-swap shape

var order = await db.WorkOrders.SingleAsync(x => x.Id == id, ct);var token = db.Entry(order).Property(x => x.Revision);Console.WriteLine($"original={token.OriginalValue}");order.ReviseSummary("Replace coupling guard before startup");order.AdvanceRevision();Console.WriteLine($"current ={token.CurrentValue}");await db.SaveChangesAsync(ct);

UPDATE "work_orders"SET "summary" = @summary,    "revision" = @newRevisionWHERE "work_order_id" = @id  AND "revision" = @originalRevision;

The current token is the version being published. The original token is the precondition. If another writer changed the stored revision after this context queried the row, the predicate matches zero rows.

2. Zero rows is the concurrency signal

For an entity configured with a concurrency token, EF expects the UPDATE or DELETE to affect the row identified by key + original token. When zero rows are affected, EF cannot safely infer that its intended state was persisted, so SaveChanges throws DbUpdateConcurrencyException.

try{    await db.SaveChangesAsync(ct);}catch (DbUpdateConcurrencyException ex){    foreach (var entry in ex.Entries)    {        Console.WriteLine(entry.Metadata.DisplayName());        Console.WriteLine(entry.DebugView.LongView);    }    throw;}

The exception tells you that the optimistic write precondition failed. It does not say which competing edit is correct. Resolution is application policy, covered in Lesson 3.

3. Deterministic two-context race: same read, ordered writes

await using var first = await factory.CreateDbContextAsync(ct);await using var second = await factory.CreateDbContextAsync(ct);var a = await first.WorkOrders.SingleAsync(x => x.Id == id, ct);var b = await second.WorkOrders.SingleAsync(x => x.Id == id, ct);Console.WriteLine(a.Revision == b.Revision); // True: same starting versiona.ReviseSummary("Dispatcher A approved bearing replacement");a.AdvanceRevision();await first.SaveChangesAsync(ct);b.ReviseSummary("Dispatcher B approved vibration-only inspection");b.AdvanceRevision();await Assert.ThrowsAsync<DbUpdateConcurrencyException>(    () => second.SaveChangesAsync(ct));

The writes are intentionally ordered. Both contexts read the same version, writer A commits first, and writer B then submits a stale predicate. This isolates optimistic stale-state detection from SQLite write-lock timing.

4. DELETE uses the same idea

var order = await db.WorkOrders.SingleAsync(x => x.Id == id, ct);db.Remove(order);await db.SaveChangesAsync(ct);

DELETE FROM "work_orders"WHERE "work_order_id" = @id  AND "revision" = @originalRevision;

If another writer changed the token first, the delete affects zero rows and surfaces a concurrency exception. Foreign-key or cascade failures are different: they typically surface as a database/provider update exception, not a token mismatch.

5. Concurrency conflict is not a deadlock, busy lock, or timeout

Blindly putting DbUpdateConcurrencyException into a generic transient retry loop can repeatedly overwrite or re-propose stale business state. Conversely, asking a user to merge after a network timeout may be equally wrong.

6. Set-based DML requires explicit concurrency predicates

Chapter 12 showed that ExecuteUpdateAsync bypasses EF's change tracker and normal automatic concurrency checking. If a set-based operation is version-sensitive, include the expected version in the filter and inspect rows affected.

var newRevision = Guid.NewGuid();var affected = await db.WorkOrders    .Where(x => x.Id == id && x.Revision == expectedRevision)    .ExecuteUpdateAsync(setters => setters        .SetProperty(x => x.Revision, newRevision), ct);if (affected == 0)    throw new WorkOrderConflictException(id, expectedRevision);

That application exception is your domain/API contract; EF does not raise DbUpdateConcurrencyException automatically for this direct set-based write.

7. Hands-on lab and evidence bundle

1. Reset SQLite and enable EF command + update logging without sensitive-data logging in shared/production-like output.
2. Run one successful tracked update and capture original/current Revision values.
3. Run the ordered two-context race and capture both UPDATE commands.
4. Verify the second command uses its stale original revision and affects zero rows.
5. Inspect ex.Entries, tracker state, and database state after the exception.
6. Repeat with a stale DELETE.
7. Implement the rows-affected pattern for one ExecuteUpdateAsync call and verify zero is handled explicitly.

8. Production judgment and bridge

Use the exception type, generated command, affected-row expectation, tracker snapshot, and database state together. Once a stale write is proved, the next question is policy: reject it, prefer the store, reapply the client proposal, or merge non-overlapping fields. Lesson 3 implements those policies without unbounded retry loops.

Authoritative references

• Handling Concurrency Conflicts - EF Core — zero-row detection and concurrency exceptions.
• Accessing Tracked Entities - EF Core — entry/property original/current values and metadata.
• Simple Logging - EF Core — capturing generated database commands for development diagnosis.
• ExecuteUpdate and ExecuteDelete - EF Core — rows-affected and change-tracker/concurrency boundaries.
• Using Transactions - EF Core — transaction semantics distinct from optimistic concurrency.
• SQLite Result and Error Codes — provider/engine lock errors such as BUSY/LOCKED.