Asynchronous programming in ADO.Net

Question

The following link http://msdn.microsoft.com/en-us/library/hh211418(v=vs.110).aspx explains the new asynchronous programming features with the 4.5 .Net framework, which for the most part is fairly straight forward reading.

However, I just want to make sure of something....

If I am using a SQLDataReader in a web service and I create a service reference on the client to use that web service by generating asynchronous methods in the proxy (via the service reference dialog options), I very well imagine I wouldn't need to use the methodologies mentioned in the link above.

Rather, I would use the async, Task, and await keywords on the client appropriately when calling that web service method

Since checking those options on the Web Service dialog, it will automatically create asynchronous method calls for the ADO.Net call.

So, if you have a method called GetCategories in the web service, it will automatically create an asynchronous call called GetCategoriesAsync in the web service which could be called from the client. Again, no need to place the asynchronous attributes on the web service method call; only for an ADO.Net call which is not using a web service or one which is using a web service, but does not have the asynchronous options checked.

Am I correct in my thinking?

Answer 1

It depends on what you want to make asynchronous.

Network communications are inherently asynchronous. When Visual Studio creates a client proxy for your web service, it creates both asynchronous and synchronous methods (where the synchronous methods just block waiting for a response). So, your web client can be asynchronous, and this is true regardless of how the server is implemented. In other words, a server can be synchronous or asynchronous, and a client can be synchronous or asynchronous, completely independent from each other.

On the client side, you should almost always use asynchronous methods on the proxy. The primary benefit on the client is responsiveness.

On the server side, you can get a scalability benefit by using an asynchronous implementation. However, if your backend is a single SQL server database, and every request hits that database, then there usually isn't a benefit from making your web service asynchronous. This is because (in that case) the scalability bottleneck is the SQL server, not the web server. OTOH, if your backend is a SQL server cluster or Azure SQL, then you can get a scalability benefit by using an asynchronous web service implementation.

The old-style common scenario was client <-> API <-> DB, and in that architecture there's no real need for asynchronous DB access. However, more and more architectures are looking like client <-> API <-> cloud storage / APIs, and that's when async really brings benefits to the API layer.