.NET Data Community Standup - Database concurrency and EF Core - Episode 1

What happens when one user is reading a record while another user is updating it? What if both users try to update the same record at the same time? In this episode of the .NET Data Community Standup, Shay and Arthur take a look at how different database isolation levels impact concurrency and performance, and then extend this to optimistic concurrency patterns supported by Entity Framework Core. This includes both manual concurrency tokens and automatic concurrency tokens like SQL Server’s “rowversion”. We’ll also dig into what happens in disconnected scenarios, and when to use the original value as opposed to the current value of the concurrency token. Finally, we’ll look at how EF Core handles optimistic concurrency with ETags when using a document database like Azure Cosmos DB.

Watch the 3-part Database Concurrency series:

⏲️ Chapters:
00:00 Countdown begins
02:40 Welcome to the .NET Data Community Standup
02:55 On today's show - Optimistic concurrency
04:15 EF Core 8.01 release
05:37 Demo
1:09:45 What's next
01:10:25 Wrap


#EFCore #dotnet #data

[after]

Excellent subject and the one that I am currently dealing with! In my web application, blazor server, I am dealing with updating aspects of projects such as time charges, progress reporting, and such. I don't expect multiple users to update a project concurrently therefore I implemented a check in check out strategy to downgrade other users to view only. My problem however is when a user opens up multiple tabs or even multiple browsers to update and monitor project aspects and monitor the effect of changing one on others. Which can cause concurrency issue with the context being out of sync. The way I approach this is by sending a signalr message to other circuits to discard and reload fresh context if one in a group changes the DB. Looking forward to the next video. Very much appreciated.

[brunosansigolo]

Fantastic episode! It provided incredibly insightful information on concurrency issues in EF Core and databases. Some points seemed quite straightforward, yet they are easy to overlook in practice. Exceptional job in highlighting these nuances! Looking forward to more content like this.

[drhdev]

This came at the exact right time. Can’t wait for more!

[JoseSilva-gtzj]

Time 46:36 - Changed from PostgreSQL to SQLite.

[kdcapparelli]

Why not to remodel the database in order to merge these two fields into one [e.g. "$10.50 USD"],
while maintaining the class as-is and letting the ORM validate and transform the data at each update ?

Wouldn't it (and the optimistic row-version lock approach, perhaps, probably) be enough
to deal with all the complications mentioned here (even in disconnected scenarios) ?

Thanks, Mr. A. Vickers and Mr. S. Rojansky, for this great content
and for being so dedicated to "the cause".

[salehdanbous]

From my personal experience, Optimistic Concurrency is far more slower than pessimistic concurrency in write heavy system when for example an account balance is updated more than 200 times in a minute and collision is certain!

[Erril-]

Great topic for this and the upcoming shows

[larshanisch]

Very good talk about concurrency issues! Tweaking the update to always write the "modified" properties is something I haven't thought about and I can see the possible bugs if you don't do it.
Question: Can I tweak a SaveChanges to ignore RowVersion when I don't care? Like the manual "set property modified" thing.

[JoseSilva-gtzj]

Time 45:26 - Changed from SQL Server to PostgreSQL.

[CarlintVeld]

Please increase fontsize a bit next time I am watching from a phone 😅

[gilbertsenyonjo]

Hello. Can you help share initial code so I can follow along

[vovcheable]

Please use bigger zoom in rider, 175% or 200% would be much better.