Question

I have a webform where I am using TPL to send email in the background since our SMTP server is slow and many users end up hammering away on the submit button out of frustration. In the past I had used System.Threading and static methods to accomplish a task that was similar – in .NET3.5, my code looked like this:

Thread t = new Thread(new ParameterizedThreadStart(SendEmail));
t.Start(txtEmail.Text);

Where SendEmail’s signature was public static void AddEmailToMailingListInBackground(object EmailString) and as I remember the method had to be static, and I had to pass the value of the TextBox txtEmail to the asynchronous method or risk losing access to the control’s value as the page lifecycle continued independently.

Now when using System.Threading.Tasks my code looks like this:

Task.Factory.StartNew(() => SendEmail(), TaskCreationOptions.LongRunning);

and the signature of SendEmail is private void SendEmail() and I access the Text property of txtEmail directly within that method.

There are two major differences that I see here. First, my asynchronous method no longer has to be static. Second, I am able to access the control values of the Page within the method long after the Page’s lifecycle would have completed if I were using Threads. These two points lead me to believe that the Page is being kept alive until all Tasks have completed or the Page lifecycle has completed, whichever comes last. I’ve tested this by debugging and stepping through the asynchronous method – the response is sent to the browser yet I’m still able to step through and access controls and their values. This MSDN article helps a little but still doesn’t really solidify my understanding of what’s happening with TPL vs the pre-.NET4 way of executing asynchronous calls.

Can anyone tell me if my thinking is correct and this is dependable behavior when using TPL with ASP.NET?
Would anyone care to elaborate further?

Answer 1

It is technically not safe to access ASP.NET objects off the ASP.NET thread. You would be much better off extracting the details that SendMail needs from the page/request and passing them through via the closure.

Also, you need to make sure you “observe” any exceptions that could happen in SendMail or the TPL will raise an exception that will crash your entire web application. You can do this with a try/catch around the SendMail call itself or chain on another continuation with TaskContinuationOptions.OnlyOnFaulted option. In the continuation approach, you just need to access the Exception property of the antecedent, presumably to log it, in order for TPL to know you’ve “observed” the exception.

So to put this all together it might look like this:

string userEmail = userEmailTextBox.Text;
// whatever else SendMail might need from the page/request

Task.Factory.StartNew(() => SendMail(userEmail))
            .ContinueWith(sendEmailAntecedent =>
                          {
                              Trace.TraceError(sendEmailAntecedent.Exception.ToString());
                          },
                          TaskContinuationOptions.OnlyOnFaulted|TaskContinuationOptions.ExecuteSynchronously);