次のシナリオを検討してください。
- 非同期 .ashx ハンドラー
- 非同期 .asmx Web サービス メソッド
- 同期 MVC 5 コントローラー アクション メソッド
「論理」httpリクエスト中に一貫してアクセスできる「論理スレッド」固有のデータを設定する方法を見つけようとしています。つまり、非同期ハンドラーの「BeginExecute」部分のスレッドでデータが設定された場合ASP.NET が別の OS/.Net スレッドで「EndExecute」部分を実行したとしても、データはその asnc ハンドラの「EndExecute」部分で利用できると考えるでしょう。
さらに、2番目のリクエストが最初のhttpリクエストに以前に割り当てられたスレッドに割り当てられた場合、それがあったOS / .Netスレッドの「BeginExecute」部分のデータセットは、後続のhttpリクエストでは利用できないと予想しています。 「BeginExecute」部分にありましたが、最初の http 要求が非同期操作に入ったときにこのスレッドが解放されました (そして、まだ非同期操作を完了している可能性があります)。
.Netの「論理スレッド」または「論理スレッドコンテキスト」という言葉は、実際には、私が言及したのと同じ「論理」操作フローを意味すると思います（再割り当てされ続ける基礎となるOS / .Netスレッドではありません）。ワークフローの観点から見ると、各 http リクエストは新しい「論理」操作です (複数のユーザーが同じ Web サービスを順次または並行して呼び出したとしても、各リクエストは新しい個別の論理操作です)。つまり、「論理」操作は 1 回限りであり、繰り返すことはできません。ただし、同じ基礎となる OS/.Net スレッドは、可用性に基づいて到着したときに「論理」操作にマップできます。
さらに、このデータを HttpContext.Current の種類の静的プロパティとして公開したいと考えています。これは驚く人もいるかもしれませんが、非同期の .asmx Web サービス メソッドなどを使用している場合、HttpContext.Current は正しく機能しません。HttpContext.Current は常に正しい HttpContext を返す必要があるという Web 上のコンテンツを読んだことがあると確信していますが、.asmx Web メソッドの EndExecuteMethod では null として表示されています。私の最後の発言が正しいかどうかを誰かが確認できれば素晴らしいことですが、この発言は私がここで尋ねようとしている全体的な質問ではありません.
かなりの量の文献を読んだ後 (例: log4net.ThreadContext と log4net.LogicalThreadContext の違いは何ですか?、http://msmvps.com/blogs/jon_skeet/archive/2010/11/08/the-importance-of-context -and-a-question-of-explicitness.aspx、http://blog.stephencleary.com/2013/04/implicit-async-context-asynclocal.htmlなど、MSDN ドキュメントを含む)、ここに私の推論があります:
- ThreadStatic は、「論理」操作ではなく、基礎となる OS/.Net スレッドに対してローカルであるため、私の例では; 2 番目の http 要求が最初のスレッドの「BeginExecute」と同じスレッドに割り当てられた場合、「BeginExecute」の最初の http 要求で設定されたデータは、次の http 要求で表示されます。そして、このデータは、たまたま .Net によって別のスレッドに再割り当てされた場合 (ほとんどの場合に発生します)、"EndExecute" で使用できません。
- Thread.SetData は、私のユースケースではさらに問題があります。データ スロットを渡す必要があります。Thread.GetNamedDataSlot の戻り値からデータ スロットを渡す場合、アプリ ドメイン全体で情報を利用できます。名前付きデータスロットはスレッド間で共有されるため。
- CallContext.SetData は ThreadStatic に似ています (つまり、アプリ ドメインによって共有されませんが、異なる http 要求が同じ基になる OS/.Net スレッドに割り当てられると、同じデータが表示されます)。CallContext.SetData は、RPC 呼び出しのコンテキスト データをマーシャリングする追加機能を提供します。これは、現在尋ねられている質問には関係ありません。
- 次に、ThreadLocal クラス (.Net 4/.Net 4.5) があります。私の問題の一部を解決できたようです.BeingExecute操作のstateObject内にそれを渡し、endExecute操作の同じstateObjectパラメータから抽出できました。この観点から、ThreadLocal は .Net の非同期サポート用に作成されているようです。ただし、HttpContext.Current のようにアクセスする必要がある場合は機能しません。その「論理スレッドの静的」インスタンスを保持する方法がないためです (前の 3 つのポイントで何か間違ったことを言っていない限り)。
- そして最後に、CallContext.LogicalSetData が私が達成しようとしていることを実行しているようです。CallContext.LogicalSetData および CallContext.LogicalGetData メソッドのセットを使用して、「論理タスクの実行」に対して正しく機能する HttpContext.Current のような影響を達成できるはずです。
では、次の質問に移ります。
- 私が上で言ったことはすべて正しいですか。私が行ったすべての誤った主張を修正してください。
- 私が見逃した.Netのスレッドの静的な種類の機能に利用できる他のオプションはありますか?
- CallContext.LogicalSetData/LogicalGetData はコンテキスト データを RPC 呼び出しに渡しますか (msdn ページでは明確に言及されていません。http: //msdn.microsoft.com/en-us/library/system.runtime.remoting.messaging.callcontext.logicalsetdata (v=vs.110).aspx )。
- CallContext.LogicalSetData/LogicalGetData を使用することの欠点 (パフォーマンス上またはそれ以外) はありますか。
- このページでは、LogicalSetData のコピー オン ライト動作について説明しています: http://blog.stephencleary.com/2013/04/implicit-async-context-asynclocal.html。非同期ハンドラー/非同期 MVC 5 アクション メソッドのコンテキストでは、logicalsetdata を使用して参照型を保存し、後で参照型の状態を変更すると、どのような影響がありますか。再帰とは何ですか。
- Mutation/logicalsetdata/async については、オブジェクトを変更しても何が問題なのかまだわかりません。非同期メソッドが開始されると、copy-on-write 動作により、次に logicalsetdata が呼び出されたときにコンテキスト データのコピーがトリガーされます。これは浅いコピーであるため、参照オブジェクトは実際には 2 つの論理コンテキストで共有され、一方のコンテキストでの変更はもう一方のコンテキストで表示されます。これは通常、参照型に期待されることです。
多くの参考文献を含む長い質問ですが、うまくいけば、私は自分の研究をうまく行い、その答えが他の人にも役立つことを願っています.