Repository navigation
Feature | Implement async transaction begin/commit/rollback methods #113
Description
.NET Core 3.0 will fill in some missing async APIs (e.g. transaction management), these should be implemented in SqlClient at some point.
Reacted by Timo van Zijll Langhout, Frédéric Delaporte, Grégoire, Joe Amenta, Antonio Freire, Robbie Groenewoudt, zabulus, artdedeco, David Engel, Nikolai Bjørndalseter and 8 more
Reacted by Eric Dugas and Frairlyn Camilo Roque Suarez
Activity
roji commentedon May 23, 2019
(note: these should hopefully also make it into .NET Standard 2.1)
Wraith2 commentedon May 24, 2019
Is there written guidance anywhere on the suggested patterns of do and don't for implementing
IAsyncDisposable?roji commentedon May 24, 2019
I'm not sure there's an "official" guide or anything, but the basic idea is to bring the instance to the same state it would have had if
Dispose()was called, except that all I/O and other blocking calls need to be done asynchronously. The rest is going to depend on your specific implementation (e.g. whether any code can be shared betweenDispose()andDisposeAsync()).[-]Implement new async methods coming in .NET Core 3.0[/-][+]Implement new async methods in .NET Standard 2.1[/+]roji commentedon Jul 29, 2020
Note this user complaint about the lack of async transaction APIs: dotnet/efcore#21818. Not sure how complex this is to implement, but I'm hoping it can be done at some point to unblock perf issues such as this.
[-]Implement new async methods in .NET Standard 2.1[/-][+]Implement async transaction commit/rollback methods[/+]tastyeggs commentedon Jan 24, 2025
I want to bump up this issue - I think it is important that this be prioritized. At a certain scale and workload type, we hit a ceiling due to this issue, and are forced to do manual transaction management (using BEGIN/COMMIT statements). I'm sure there are many users who aren't aware this issue even exists, and simply scale up their application more than they need to.
nikolai-mb commentedon Feb 19, 2025
This also seems to be a partial blocker preventing Hangfire from fully adopting the async pattern in the job scheduler if my understanding is correct. Lack of proper async in the SqlClient seems to be causing quite a bit of friction in both MS and third-party libraries alike
mdaigle commentedon Mar 27, 2025
Should also cover
BeginTransactionAsyncvRune4 commentedon Mar 28, 2025
I'd like to echo this sentiment. We've been battling thread starvation-like symptoms for months now and seeing that transaction commit is synchronous does little to help us find the real culprit (maybe Commit() is the real culprit in the end for all I know...).
Also: Our problems started after trying to migrate to Azure. Running on a couple of VMs in a local data center churns out a heckuva lot more IOPS and better latency than what is currently on offer in Azure. We keep throwing more and more vCPUs on the problem but synchronous IO is killing us. (and reading about the sqlclient's connection pool also does little to boost my confidence)
(For the curious: We had two 4 CPU VMs in a local datacenter. One running SQL Server and another our two services. Now we have 6 vCPUs handling our Managed SQL instance and 4+8 vCPUs for our two containers. Our azure environment can handle less than half the load of our "obsolete" configuration)
[-]Implement async transaction commit/rollback methods[/-][+]Implement async transaction begin/commit/rollback methods[/+][-]Implement async transaction begin/commit/rollback methods[/-][+]Feature | Implement async transaction begin/commit/rollback methods[/+]priyankatiwari08 commentedon Sep 17, 2026
/triage
Frulfump commentedon Oct 25, 2026
Did the triage command fail?