Concurrency Handling in Entity Framework Core with Transactions and Master Data

Thanks for your quick response. In our .NET Core microservice system with Entity Framework, we're using ReadCommitted isolation level and have a RowVersion column for optimistic locking in the transaction table. However, the master table lacks a RowVersion column. Will this approach effectively prevent concurrency issues, or do both tables require a RowVersion column for guaranteed consistency?

Please use the add comment section to respond to answers. We cannot tell who you're responding to.

In regards to this question, no there will not be a concurrency exception unless you actually change the customer data. Again, EF doesn't update objects unless it detects that you made a change. If you aren't changing anything on the customer then it won't push anything to the DB and concurrency problems won't happen.

If you will be making changes on multiple requests at the same time AND you want to fail one of the calls so the last writer doesn't win then add a concurrency token to the table. If there is no concurrency token on the table (and you didn't add one) then a concurrency error won't occur. EF just stomps over whatever was there before (hence the last writer wins).

If concurrency is a concern then add a concurrent column on the table. EF will handle the rest. You probably want to annotate your field in the code as the concurrency token just to be sure but EF will throw a concurrency error if the token doesn't match what it was when it was read.

A very big caveat to this approach - it only works if the concurrency token is persisted along with the rest of your data on the client side. Example.

var customer = await context.Customers.FindAsync(1);
customer.Name = "Bob";

//Concurrency error IF somebody else grabs the same customer after you get the data
//AND updates the customer and saves it back to the DB
await context.SaveChangesAsync();

If you query the DB for the data and then update the properties and save it back then you're updating the data as it exists in the DB at that point. In this case the odds of a concurrency error are very small but that doesn't mean this code is concurrency safe. Imagine this adjusted scenario.

//Display data to user to edit
var customer = await context.Customers.FindAsync(1);
//assume: customer.ConcurrencyTokoen = 1

//Time elapses while user interacts with UX

//Another request comes in and customer Name is changed to something else
//concurrency token is updated in DB as well
//assume: customer.ConcurrencyToken = 2

//Client clicks "save" which triggers the following series of calls
var customer = await context.Customers.FindAsyn(1);
//customer.ConcurrencyToken = 2  
customer.Name = "Bob";

await context.SaveChangesAsync();

Since your "save" code gets a fresh copy of the customer it also gets all the updated data including the new concurrency token. Since your UX had the original data it is going to stomp over whatever changes were made by the other request AND it won't detect a concurrency change because when you fetched the data to save it you got the current token value.

To work around this you'd need to persist the concurrency token in your UX (or wherever) and when updating the customer you need to ensure you use the concurrency token that you persisted from the original fetch.

//Saving the data
var customer = await context.Customers.FindAsync(1);

//Update all the fields that need to change including the concurrency token
customer.Name = "Bob";
customer.ConcurrencyToken = //value that was retrieved when you originally fetch the data

//Will blow up if the concurrency token that you got the first time doesn't match up with what it is now
await context.SaveChangesAsync();