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

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.

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.

[OskarKlintrot]

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.

[OskarKlintrot]

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.