ASP.NET 4.0でタスクパラレルライブラリを使用する場合の明確化

Question

私はSMTPサーバーが遅く、多くのユーザーが欲求不満のために送信ボタンを押してしまうので、私はTPLを使ってメールをバックグラウンドで送信しています。過去に私は類似していたタスクを達成するためにSystem.Threadingと静的メソッドを使用していた - .NET3.5で、私のコードは次のように見えた：私はこの方法がなければならなかった覚えているのsendEmailの署名がpublic static void AddEmailToMailingListInBackground(object EmailString)だったと

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

静的でなければならず、非同期メソッドにTextBox txtEmailの値を渡すか、ページライフサイクルが独立して続行されるため、コントロールの値へのアクセスが失われる危険があります。 System.Threading.Tasksを使用した場合

は今、私のコードは次のようになります。

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

とのsendEmailの署名がprivate void SendEmail()と私は直接そのメソッド内txtEmailのTextプロパティにアクセスします。

ここには2つの大きな違いがあります。まず、私の非同期メソッドはもはや静的である必要はありません。次に、スレッドの使用中にページのライフサイクルが完了した後、メソッドの中でPageのコントロール値にアクセスすることができます。これらの2つのポイントは、すべてのタスクが完了するかページのライフサイクルが完了するまでの間に、ページが生きていると信じるようになります。私は、非同期メソッドをデバッグして実行することでこれをテストしました。レスポンスはブラウザに送信されましたが、まだコントロールとその値にアクセスしてアクセスできます。 This MSDN articleはちょっと役立ちますが、まだTPLと非同期呼び出しを実行する前の.NET4の方法との違いを理解しているわけではありません。

誰も私の思考が正しかったのか、これはASP.NETでTPLを使用しているときに信頼できる動作であると言えますか？
さらに詳しく説明してもらえますか？

Answer 1

ではありません。 ASP.NETオブジェクトからASP.NETスレッドに安全にアクセスできます。 SendMailがページ/リクエストから必要とする詳細を抽出し、クロージャを介してそれらを渡すほうがずっと良いでしょう。

また、SendMailで発生する可能性のある例外を "観察"する必要があります。そうしないと、TPLは例外を発生させてWebアプリケーション全体をクラッシュさせます。これは、SendMail呼び出し自体の周りのtry/catchや、TaskContinuationOptions.OnlyOnFaultedオプション付きの別の継続の連鎖で行うことができます。継続的なアプローチでは、TPLがあなたが例外を「観察」したことを知るために、前回のExceptionプロパティにアクセスするだけで、おそらくログに記録する必要があります。だから、すべて一緒に、それは次のようになります。これを置くため

：

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