I want to recommend you about a great article that was written by a friend of mine - Boaz Davidoff, about duplex web services.

He found a great way for multiple clients to communicate through web services that push events/messages to the client.

I will not get down on details here (this you can read on the article), but this is a great example of server-side multi-threading techniques.

I read some related stuff about this issue on the web and found that Microsoft covered this solution under the WCF environment, but my POC has proven that Boaz's solution is much more easier to understand (if you don't have the minimal knowledge on WCF) and to implement or customize to your own requirements.

So if you have a client application that requires real time information to be pushed from the server, or from other clients, this might be the ticket. 

The article is on the codeproject.com site here.

I had a performance problem in my current working on web application; In one of my flows in this application, I had needed to call the database and to update some large amount of data over there, but this action had taken lots of time and the outcome was that users had to wait a long time until this action will be done, admit it, it is frustrating...

My first kind of solution to this problem was to create a new thred from the IIS's thread pool and to assign this action under it - quite good resolution not? BUT, I reminded that asp.net 2.0 (also 1.X) already implements it in a better and friendly way, using Asynchronous Pages.

But first, some Background...
As we all know (or not), when ASP.NET receives a request from the user, it ask for a thread from a thread pool and assigns that request to the thread. In order to this action, the synchronous page holds this thread for the duration of the request, and preventing it from being used by other requests. That leads us to my problem: when I am calling to the database and doing the long long action (an UPDATE query), the thread assigned to the request is stuck doing nothing until the call returns. (This happens because the thread pool has a finite number of threads available).

The Resolution is (of course) Asynchronous Pages.

Asynchronous pages offers a neat solution to such kind of problems. Once an asynchronous operation begins in response to a signal from ASP.NET, the page returns the used thread to the thread pool. When this operation completes, this mechanism asks for another thread from the thread pool and finishes processing the request. This mechanism helps us to manage more efficiently the threads manipulation from the thread pool, because threads that were stucked earlier, now can be used for other porpuses.

Lets see some code:

Firstable, you need to set the Async property on the top on the asp.net page in order to use this thing:

<%@Page Language="C#" Async="true" ... %>

This property set to true, says the page to implement the IHttpAsyncHandler. Regarding this, you need to register the Begin method and End method of to the Page.AddOnPreRenderCompleteAsync.

// Register async methods
AddOnPreRenderCompleteAsync(
   new BeginEventHandler(BeginAsyncOperation),
   new EndEventHandler(EndAsyncOperation)
);

By these actions, the starts its normal life cycle, until the end of the OnPreRender event invocation. At this point the ASP.NET calls the Begin method that we registered earlier and the operation begins (calling the database etc...), meanwhile, the thread that has been assigned to the request goeas back to the thread pool. At the end of the Begin method, an IAsyncResult is being sent automatically to the ASP.NET and let it determine in the operation had completed, a new thread is being called from the thread pool and there is call to the End method (that we registered earlier, remmember?).

Note: We do not need to implement the IAsyncResult interface, the Framework implements it for us.

The Begin and End Methods:

IAsyncResult BeginAsyncOperation (object sender, EventArgs e, AsyncCallback cb, object state)
{
   // Do your things...
   // Call the DB and run the long long query...
}

void EndAsyncOperation(IAsyncResult ar)
{
   // Do your things...
   // Get a response from the DB that the operation is DONE...
}

Nide ahhhu? So use it wisely...