Hi I am using WCF Services exposed as REST URIs to be consumed by generic AJAX clients. All of my services need to be Async in nature. We have a typical n-layer architecture for our project wherein the Service Layer --> Business Layer and Business Layer --> Data Access Layer Data Access Layer --> LINQ --> DB The heaviest part of the processing will be fetching and sending updates to the database. As such this part needs to be made asynchronous. Earlier, we had thought that the service layer would simply accept the calls. It would then use ThreadPool.QueueUserWorkItem to spawn a secondary thread and move the calls to the Business Layer onwards to this secondary thread. For e.g. public IAsyncResult BeginGetData(params) { //Create an AsyncResult ThreadPool.QueueUserWorkItem(SomeCallback, AsyncResult) //Return AsyncResult } private void SomeCallback(object state) { //Call BUSINESS Layer which calls Data Access Layer and so on. } public string GetData(AsyncResult) { } But this defeats the purpose of Async operations since we end up using threads from the same thread pool as ASP.Net for the WCF services. A load test confirmed this too. The performance was worse than a synchronous WCF service call. An article I read on Async HTTP handlers mentioned the same. Do I need to split my Business Layer and Data Access Layer methods into Begin and End pairs too? Or is there a better way. Kindly let me know, what is the preferred way of handling this as I am sure that this would be a problem faced commonly. Thanks in advance Vikas Manghani
