Asp.net mvc processing a task asynchronously

I am working on asp.net mvc application that has one of the requirement as below.

Scenario : User submits a request to process long running task. The task will have to be initiated on the server side. And without wai开发者_开发百科ting for the task to get completed, a response has to be sent to the user saying that once the task gets completed , they will get an email notification.

This seems to be a scenario for asynchronous processing. Initially I thought of using asynchronous delegates but came to know that asynchronous delegate will run as background thread and will not stay alive if the main thread exits.For me it seems , once the response is sent to the user, the main thread exits and so as background thread. Correct me if I am wrong on this.

So I thought of creating a foreground thread using Thread class. But in one of the articles I have read,it is mentioned that asp.net will not look at whether its a foreground thread or not and will not be useful. Is it true?

I am currently looking at the following atlernatives . Please suggest

1. Moving out the task processing logic outside of asp.net and put in console app/service and notify the app by pushing message from asp.net to MSMQ. Once the message is received,the console app will do the processing and send an email notification

2. A WCF service to receive the message and do the processing

Any other better ideas please share

Thanks,

Sveerap

You could simply use:

ThreadPool.QueueUserWorkItem(o =>
                                    {
                                        // do something aync
                                    });

Previous comments on this:

There are lots of arguments about starving the thread request pool by doing this (which is true), but the counter argument is you should starve the pool because the server is busy doing work. Of course ideally you should move the work off onto another server entirely via queuing/distributed systems etc, but that's a complex solution. Unless you need to handle hundreds of request you do not need to consider this option, as it'a unlikely it would ever cause an issue. It really depends of the scalability requirements of your solution, how long the background process is going to take, and how often it is called.