2

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 waiting 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

tereško
  • 58,060
  • 25
  • 98
  • 150
sveerap
  • 841
  • 1
  • 9
  • 20

1 Answers1

0

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.

Community
  • 1
  • 1
TheCodeKing
  • 19,064
  • 3
  • 47
  • 70
  • I think ThreadPool.QueueuserWorkItem creates a background thread and since background threads cease to exist once the main thread is done, will it not create problem in the above scenario? – sveerap Sep 07 '11 at 12:56
  • No it definitely won't, it will create a new thread from the thread pool and the request thread can terminate. – TheCodeKing Sep 07 '11 at 13:06
  • Thanks for the reply. But how can we say that thread will not get terminated at all when the threadpool threads are background – sveerap Sep 07 '11 at 13:41