.NET Data Community Standup - Database concurrency and EF Core

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

Рет қаралды 9,242

4 ай бұрын

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:
kzfaq.info/sun/PLdo4fOcmZ0oUaC54XKb1miYBaTFc3H17z
⏲️ 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
Featuring: Shay Rojansky (@andshayrojansky) Arthur Vickers and Alice 🐈‍⬛
#EFCore #dotnet #data

Пікірлер: 16

@brunosansigolo 4 ай бұрын

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.

@after2003 4 ай бұрын

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.

@mirkogeffken2290 4 ай бұрын

It gets soooo much more complicated if you don’t want to lock the tables, but need consistent updates across rows, like aggregates. Great talk. Developers job really is to think about how can this go wrong and do we care enough to invest effort. In critical scenarios you need to let the user know that what they based their edits on is now bunk and they may need to start over. Sensing that is where this is headed ;)

@erril8285 3 ай бұрын

Great topic for this and the upcoming shows

@drhdev 4 ай бұрын

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

@JoseSilva-gt6zj 3 ай бұрын

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

@kdcapparelli 4 ай бұрын

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".

@salehdanbous6783 4 ай бұрын

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!

@JoseSilva-gt6zj 3 ай бұрын

Time 46:36 - Changed from PostgreSQL to SQLite.

@larshanisch 4 ай бұрын

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.