question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Increase in lost lock after upgrading to .NET 7, EF Core 7 and Microsoft.Data.SqlClient 5.0.1

See original GitHub issue

We’ve seen a dramatic increase in number of lost locks since we upgraded to .NET 7 and EF Core 7. EF Core 7 uses Microsoft.Data.SqlClient (>= 5.0.1) but EF Core 6 used Microsoft.Data.SqlClient (>= 2.1.4) (DistributedLock.SqlServer have a dependency to Microsoft.Data.SqlClient (>= 2.1.1)).

We started upgrading our services before Christmas and around the same time the amount of lost locks started to increase from a few a week to 10-50 a day.

image

The only change we have done that we figure might have an impact is upgrading from .NET 6 to .NET 7 and Microsoft.Data.SqlClient from 4.1.0 to 5.0.1.

Issue Analytics

  • State:closed
  • Created 8 months ago
  • Comments:21 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
OskarKlintrotcommented, Feb 24, 2023

Sorry, got buried in other work. Closing this for now and tracking the issue here. Might re-open this issue if Microsoft.Data.SqlClient don’t think it has anything to do with them.

1reaction
OskarKlintrotcommented, Jan 18, 2023

If the connection is broken, I would expect disposing the handle to throw an exception since it will try to execute the release sproc and that will fail. Are you seeing any exceptions there?

I made a mistake and didn’t realize that there could be an exception thrown from there. I accidently suppress any exceptions thrown during dispose. I’ll have to fix that and deploy the services.

Are you able to repro this at all locally? I assume not since you said just in acceptance test…

Unfortunately, no. Maybe if I leave a job running for a few days on a computer but I’ll hope I can get some exceptions that makes sense from production instead.

Is it possible for you to try and repro this without subscribing to HandleLostToken? I want to try and isolate whether this is an issue that is being caused by handle monitoring or whether it is being detected by handle monitoring.

Sure, I think I could just use .WasLost() instead so I still can log when the lock have been lost. I’ll start with logging the exceptions to get a picture of what is happening before I change.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Increase of exceptions thrown after upgrading to .NET 7 ...
Describe the bug We've seen a dramatic increase of exceptions thrown after upgrading to .NET 7 and EF Core 7. EF Core 7...
Read more >
Breaking changes in EF Core 7.0 (EF7)
This is a severe breaking change in the Microsoft. Data. SqlClient package. There is nothing that can be done in EF Core to...
Read more >
What's New in EF Core 7.0
Overview of new features in EF Core 7.0.
Read more >
Tutorial: Handle concurrency - ASP.NET MVC with EF Core
This tutorial shows how to handle conflicts when multiple users update the same entity at the same time.
Read more >
asp.net core 5 application and microsoft.data.sqlclient
I'm working on an asp.net core 5 application. Trying to use Microsoft.Data.SqlClient on development machine and it works, but after installing ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found