ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple) の WCF サービスがあります。ThreadStatic 変数を使用してデータを取得したいと考えています。
同じまたは異なる operationContracts に対する 2 つの並列要求が同じスレッド サーバー側で処理される可能性があるのではないかと心配し始めます。これが発生すると、ThreadStatic 変数がオーバーライドされるためです。 )
同じ ServiceBehaviour と maxConcurrentCalls="2" でスパイク サービスを作成しました。その後、wcf クライアントが 50 の並列リクエストでサービスを呼び出しましたが、私の心配は発生しませんでした。ただし、これは 100% の証拠ではありません。
少し早いですがお礼を！
ConcurrencyModeに関係なく、ThreadStatic要求が終了してスレッドがスレッドプールに返されるときに値が保持されます。同じスレッドを後続のリクエストで再利用できるため、ThreadStatic値を確認できます。
明らかに、これは2つの同時リクエストには当てはまりません。これは、定義上、これらは異なるスレッドで実行されるためです。
コメントから：
また、定義上、MSDNは次のように述べています。'サービスインスタンスはマルチスレッドです。同期の保証はありません。他のスレッドはいつでもサービスオブジェクトを変更できるため、同期と状態の一貫性を常に処理する必要があります。したがって、それはそれほど明白ではありません:)
これは、サービスクラスの単一のインスタンスに複数のリクエストで同時にアクセスできることを意味します。したがって、サービスクラスのインスタンスメンバーへのアクセスの同期を処理する必要があります。
ただしThreadStatic、メンバーは定義上、一度に1つのスレッド（したがって1つの要求）によってのみ使用されるため、同期は必要ありません。
あなたの質問に対する直接の答えは、ジョーの答えです。
ただし、アンビエント デザイン パターンを使用しているとコメントで述べています。このパターンは WCF で OperationContext として既に実装されており、特に拡張できるように設計されています。カスタム スレッド ストレージよりも OperationContext を使用することを強くお勧めします。
ここでジョーの回答に追加したかったのは、状態を保存する必要がある場合は、リクエストに何らかの相関関係を使用することをお勧めするからです。スレッド化モデルは非常に複雑になり、本番環境では信頼できなくなります。
さらに、このサービスをホストする 2 つの IIS サーバーと、それを利用できるように前向きのハードウェアまたはソフトウェアのロード バランサーがあるとします。サービスが開始されるサーバーがわからないため、正しい状態を確実に収集するには相関が必要です。以下の投稿では、それがどのように機能するかを簡略化したモックアップを作成しました。留意すべきことの 1 つSessionStateは、サービスのすべてのインスタンスに対して共有の場所 (AppFabric キャッシュ サーバーなど) に保持する必要があることです。