asp.net - 关于在 ASP.NET 4.0 中使用任务并行库的说明

Question

我有一个网络表单，我在后台使用 TPL 发送电子邮件，因为我们的 SMTP 服务器速度很慢，许多用户最终出于沮丧而敲打提交按钮。过去我用过 System.Threading和静态方法来完成类似的任务 - 在 .NET3.5 中，我的代码如下所示:

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

SendEmail 的签名在哪里 public static void AddEmailToMailingListInBackground(object EmailString)我记得该方法必须是静态的，我必须将 TextBox txtEmail 的值传递给异步方法，否则随着页面生命周期独立继续，可能会失去对控件值的访问权限。

现在使用时 System.Threading.Tasks我的代码是这样的:

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

SendEmail的签名是 private void SendEmail()我访问了 Text txtEmail 的属性(property)直接在该方法中。我在这里看到了两个主要区别。首先，我的异步方法不再是静态的。其次，如果我使用线程，我可以在 Page 的生命周期完成很久之后在方法中访问 Page 的控件值。这两点让我相信页面一直保持事件状态，直到所有任务完成或页面生命周期完成，以最后一个为准。我已经通过调试和单步执行异步方法对此进行了测试 - 响应被发送到浏览器，但我仍然能够单步执行并访问控件及其值。 This MSDN article有一点帮助，但仍然没有真正巩固我对 TPL 与执行异步调用的 pre-.NET4 方式发生的事情的理解。
谁能告诉我我的想法是否正确，并且在将 TPL 与 ASP.NET 一起使用时这是可靠的行为吗？有人愿意进一步详细说明吗？

Answer 1

从 ASP.NET 线程访问 ASP.NET 对象在技术上是不安全的。您最好从页面/请求中提取 SendMail 需要的详细信息并通过闭包传递它们。

此外，您需要确保“观察”可能发生在 SendMail 中的任何异常，否则 TPL 将引发一个异常，该异常将使您的整个 Web 应用程序崩溃。您可以通过围绕 SendMail 调用本身的 try/catch 或使用 TaskContinuationOptions.OnlyOnFaulted 选项链接另一个延续来完成此操作。在延续方法中，您只需要访问先行词的 Exception 属性，大概是记录它，以便 TPL 知道您已经“观察到”了异常。

所以把这一切放在一起，它可能看起来像这样:

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);