I am wondering how much benefit you get from using async http requests if not all parts of your code is async.
Lets consider to scenarios: 1) async http requests blocking on sync database calls, and 2) sync http requests awaiting async database calls.
1) Web Api supports async action methods, but if I do a sync database call when handling the request, then the thread blocks on the call, and I will not get the benefits of better thread economy that async could give me or what?
2) If I have a synchronous ServiceStack service call that awaits an async database call, then what happens? I assume a thread is reserved for handling the entire sync http request, and when this thread awaits an async call then it is still reserved to the web request or what ?
Basicallly my question can be boiled down to this: Is there any reason to use async if not all IO calls are async?
On the server side, there is usually no benefit in a partially-async solution.
1) Web Api supports async action methods, but if I do a sync database call when handling the request, then the thread blocks on the call, and I will not get the benefits of better thread economy that async could give me or what?
Correct. As soon as you do a synchronous (blocking) database call, you are tying up a thread for the duration of that call. So the benefits that you would have gotten from async do not apply.
2) If I have a synchronous ServiceStack service call that awaits an async database call, then what happens? I assume a thread is reserved for handling the entire sync http request, and when this thread awaits an async call then it is still reserved to the web request or what ?
This is just the same as a synchronous database call. Under the covers, a synchronous database call executes the actual call asynchronously and then blocks the calling thread until it completes. So you still have a thread blocked for the duration of the call, and you don't get any async benefits.
Basicallly my question can be boiled down to this: Is there any reason to use async if not all IO calls are async?
There are a few more obscure scenarios. You can use Task.WhenAll to do a limited type of concurrency, which is much easier with async than other forms of asynchronous concurrency. But that's the only benefit I can think of if you don't have a fully-async stack.
It basically boils down to what the calling code can do while the async call is being done. Your first example is a good fit for this. The UI can go about doing other things when a save method is called. It doesn't matter what is going on behind the scenes within the method...control has been given back to the application to continue about its way.
Your second example just means that the servicestack service could do something while the async database call is being done. But if it isn't doing anything, there isn't any real reason to use an async call to begin with.
What the async method does during its workload is not as important as what the calling application can do during the call.
