How do I keep a task alive after the method that called it has exited?

Question

I'm writing a webservice that drops off a long-running bulk insert command to a sql db through a stored proc. I don't want the webservice hung up while waiting for a response from the db, so I'd like to just return an http response that lets the client know the request has been sent to the db after I start the task. But as soon as I return the response, the task will lose context and get trashed, right? How should I keep this alive?

Answer 1

In general, it's not a good idea to spin off something to do work from IIS. What happens if the AppPool restarts? What happens if there is an exception?

Instead, I would recommend writing a Windows Service and have it responsible for the work.

Based on your comments, I would see if you can ask for the following requirements (theoretically):

All external calls are done through the web service. The web service uses a separate assembly for the actual data access.

A separate windows service is used for long running processes, which would also use the same data access assembly the web service uses.

That is really the best way to go (but not necessarily doable based on requirements).

Answer 2

I think it's more of a architecture question than just about maintaining the 'context'. And talking about architecture, I think WCF webservices would help in your scenario.

What you would need is a service with callback contract. Where the service takes a request, returns an ack, stores the client context (for callback), and triggers off a long running database task in background. When the task completes, it reads client context and calls the callback handler with the result.

This article at MSDN suggests how to do a callback contract in webservice.

Hope this helps!