Become a better .NET developer in 5 minutes a week.

Friday, 4 PM. Support ticket: "Customer charged twice for the same item."

Two orders for the same product hit the API within 200 milliseconds of each other. Both reads saw stock = 10. Both writes saved stock = 9. The warehouse shipped one item. The customer was billed for two. And nothing in the logs flagged it as a problem - because to the API, both updates succeeded.

That was the third time I had watched the same bug ship in three years. Every single time, the root cause was the same: a developer used EF Core's ConcurrencyCheck instead of IsRowVersion(), and somewhere in the codebase, someone forgot to update the version manually.

---

The Line Everyone Forgets

ConcurrencyCheck looks innocent. You add an attribute to your entity, you increment the version on every update, and EF Core uses it in the WHERE clause to detect conflicts. Easy.

public class Product
{
    public Guid Version { get; set; }
}

// In your service
product.Stock = newStock;
product.Version = Guid.NewGuid(); // ← forget this once, and you ship silent corruption
await context.SaveChangesAsync();

Forget that one line in one code path - a quick admin script, a background job written at 11 PM, a hotfix shipped on a Friday - and EF Core has nothing to compare against. The save succeeds. The conflict goes undetected.

What I Use Instead

IsRowVersion(). The database manages the version automatically. There is no manual line to forget.

public class Product
{
    public uint RowVersion { get; set; }
}

// Fluent API config
entity.Property(p => p.RowVersion).IsRowVersion();

That's the entire change. On PostgreSQL, this maps to the xmin system column - which already exists on every table. Zero migration. Zero schema cost.

Read the full guide

Optimistic concurrency in EF Core 10

→

---

If you're building APIs with dotnet, I made a free course that covers this and 100+ more lessons - from zero to production. 12,500+ devs are already in.

Start the free course →