Question

So I’ve been told what I’m doing here is wrong, but I’m not sure why.

I have a webpage that imports a CSV file with document numbers to perform an expensive operation on. I’ve put the expensive operation into a background thread to prevent it from blocking the application. Here’s what I have in a nutshell.

protected void ButtonUpload_Click(object sender, EventArgs e)
{
    if (FileUploadCSV.HasFile)
    {
        string fileText;
        using (var sr = new StreamReader(FileUploadCSV.FileContent))
        {
            fileText = sr.ReadToEnd();
        }

        var documentNumbers = fileText.Split(new[] {',', '\n', '\r'}, StringSplitOptions.RemoveEmptyEntries);

        ThreadStart threadStart = () => AnotherClass.ExpensiveOperation(documentNumbers);
        var thread = new Thread(threadStart) {IsBackground = true};
        thread.Start();
    }
}

(obviously with some error checking & messages for users thrown in)

So my three-fold question is:

• a) Is this a bad idea?
• b) Why is this a bad idea?
• c) What would you do instead?

Answer 1

A possible problem is that your background thread is running in your web sites application pool. IIS may decide to recycle your application pool causing the expensive operation to be killed before it is done.

I would rather go for an option where I had a separate process, possibly a windows service, that would get the expensive operation requests and perform them outside the asp.net process. Not only would this mean that your expensive operation would survive an application pool restart, but it would also simplify your web application since it didn’t have to handle the processing.

Telling the service to perform the expensive process could be done using some sort of inter-process communication, the service could poll a database table or a file, or you could use a management queue that the service would listen to.

There are many ways to do this, but my main point is that you should separate the expensive process from your web application if possible.