LLBLGen has CommitAsync on 5.8.

SelfServicing's Transaction class and Adapter's DataAccessAdapter class now have a CommitAsync method. This is effectively the same as the synchronous Commit method, however it will now persist audit entities asynchronously instead of synchronously. The Unit of Work's CommitAsync() method will call this CommitAsync method now as well.

I am trying to understand what's the brouhaha over SqlTransaction.CommitAsync in these threads. Does it have any practical reason for a transaction to simply have Commit vs CommitAsync?

• https://github.com/dotnet/SqlClient/issues/2215
• https://github.com/npgsql/npgsql/issues/5865
• https://github.com/dotnet/runtime/issues/1420

People see a call to a remote system and immediately want it to be async and if it's not async, then it has to change, because async is apparently the best.

But async is only possible if there are io completion ports implemented so the callee can yield till the operation has been completed: somewhere something has to wait for the operation to complete. With Commit, there's no waiting: the client simply issues a transaction commit to the DB and returns. It doesn't wait. So implementing that as async is... weird, as there's nothing there that will do the waiting for you nor is there an operation that requires waiting (and therefore offers room for improvement by yielding till the operation has been completed).

It's interesting npgsql is planning to throw an exception for an operation that's not async to begin with if you call the sync variant. I'm so tired of the asp.net team running the show. Like there's no other application type using .net. It's nice they have their system designed around a rapid switching of tasks in a queue but not all systems work like that. Besides, you don't need async to do things in parallel without waiting. The designer doesn't wait for anything and doesn't use a single line of async either: I implemented a couple of dispatch queues on the TPL and simply schedule the work to be done on one of the queues. It can auto add work if work produces more jobs.

Similar how high-performance 3D game engines work: per core a job queue.

Regarding the 2nd and 3rd link: to pull this off for npgsql they need async in transactionscope, or drop it entirely. Also if they're all-in for ditching sync IO, then not having async in transactionscope is like dropping transactionscope entirely. Now, if only the asp.net team needed it, then it would have been implemented already