Dan Balla

@JeffRichter:Thank you.

PS. I must confess, your last book that I've read is an old edition of "applied .net framework programming". I will pick up your latest CLR via C# today

Hi Jeff

Could you please explain one more thing: I have created a simple test service invoking a slow sql command in order to observe the thread consumption (listed here https://gist.github.com/1032983). When my test client hits the service with n concurrent requests, if the service is running the query synchronously I notice about n worker threads and n IO threads being allocated for the duration of the calls, as expected. When the service is running the query asynchronously, I notice about n worker threads and 0 IO threads being used. Why does WCF hang on to those worker threads? Are they locked just because the WCF connection is open? Or is it that I am doing something stupid? Is there any way to work around this?

Thanks

Dan

@JeffRichter:Thanks Jeff. That makes sense.

Hi Jeff
Thank you for an awesome session. I apologize if I am missing the obvious, but would you mind giving me a little more detail on how would you implement the described async scenario? As far as I can see, at some point something has to lock and wait for the time-consuming operation. How can you do that in a manner that would release the thread back to the threadpool? Take for example your slow database scenario: if this is called from a WCF operation that has to return the result to the client, it will need to employ something like a waithandle to await the result. As far as I know the waithandle will not release the thread.
What I have done in the past was to push the "locking" all the way to the client so that the initial command going through IIS does nothing but delegate to another process, and then the client polls another service operation for the result. I was even thinking of improving this using websockets. However if this could be achieved all in process it would be a much more elegant solution.
Thanks,
Dan