Asynchronous processing in SQL Server vs. .NET Asynchronous processing

Question

What\'s is the advantage of using Asynchronous processing in SQL Server over .NET Asynchronous processing? Aren\'t they the same? I have a hard time to understand what is th

Answer 1

The problem with .NET asynchronous processing (BeginInvoke(...)) is that all this is doing is spinning off a thread to process the code synchronously. A 5 minute query will tie up a thread for 5 minutes, blocking (i.e. doing nothing for ~99% of the time) while a result is calculated at the remote end. Under strain (many queries at once) this will exhaust the threadpool, tying up all threads in a blocked state. The threadpool will become unresponsive and new work requests will suffer big latency waiting for the threadpool to fire up extra threads. This is not the intended use of the threadpool, as it is designed with the expectation that the tasks it is asked to complete are to be short-lived and non-blocking.

With Begin/EndAction APM pairs, one can invoke the same action in a non-blocking way, and it is only when the result is returned via an IO completion port that it is queued as a work item in the threadpool. None of your threads are tied up in the interim, and at the point that the queued response is dealt with, data is available meaning user code does not block on IO, and can be completed quickly... a much more efficient use of the threadpool which scales to many more client requests without the cost of a thread per outstanding operation.