6

I am coding an ASP.NET MVC 3 app. When a user logs in I need to check a remote system and get the latest data for that user from the system. This task will take approx 15 seconds.

The user should be able to enter my app straight after their login (not have to wait for 15s for the remote call!). When the remote call completes the users local information will be updated.

I was thinking of using a thread to do this, creating it after they have logged in and letting it run its course. However, after reading around, I am concerned about recycling etc when working with threads in MVC. I would use an async controller, but I dont need to feedback to the user the state of this background process. Am I right to be concerned about threads, even if they are short-lived?

tereško
  • 58,060
  • 25
  • 98
  • 150
matt
  • 247
  • 3
  • 13

2 Answers2

5

"...concerned about recycling..."

"...don't need to feedback to the user the state..."

"...short-lived..."

3 reasons why you should be using ThreadPool.QueueUserWorkItem.

James
  • 80,725
  • 18
  • 167
  • 237
  • This is exactly what I need. I wanted the confidence to throw the command at a thread and get on with returning a page. – matt Sep 11 '12 at 08:26
0

Do not use "threads" in an web app. Let the server handle this by using "async" calls. Otherwise you would have to setup a threadpool and que the slow request.

jrb
  • 1,708
  • 2
  • 13
  • 20
  • I was under the impression await/async wasn't really meant for implementing background tasks. (As opposed to implementing sequential flows that involve long-running operations without blocking.) – millimoose Sep 10 '12 at 14:43
  • It's getting data from ANOTHER server. AsyncController will setup the request then release the thread until there is a response. – jrb Sep 10 '12 at 14:55