問題タブ [operationcontext]

OperationContext.Current オブジェクトを WCF サービス ホスト インスタンスのインスタンス変数に格納して参照することが賢明かどうかを知りたいと思いました。サービス ホストは InstanceContextMode.PerCall に設定されているため、すべての新しいリクエストは独自のインスタンスを取得します。

これを尋ねる理由は、WCF がスレッド アフィニティを保証しないためです。場合によっては、WCF が 1 つのスレッドで要求を開始し、別のスレッドで要求を終了することがあります。

OperationContext.Current オブジェクトは Thread Local Storage に格納されます。同じ操作に新しいスレッドが使用されると、WCF は新しいスレッドに "伝達" されます。

この場合、WCF が別のスレッドの使用を開始した場合、サービス インスタンスのインスタンス変数に格納された OperationContext オブジェクトにアクセスしても安全ですか?

アプリケーション (.NET、C#) で進行中の操作に特定のコンテキストを実装して、アプリケーションによって開始および実行されるコードがそれにアクセスできるようにしたいと考えています。

問題は、特定の API が行っているように、コンテキストがオブジェクトとして渡されないことです。

この静的クラスが各操作のコンテキストを提供できる WCF の OperationContext に似たものを実装したいと思います。

そのようなシステムをどのように実装できますか?

使用例:

当社のアプリケーションは、当社の SDK にアクセスできる人が作成したサードパーティの「プラグイン」を読み込んで実行します。

このようなユーザー コードは次のようになります。

この例によると、必要なのはいくつかの静的 Context クラスだけですが、アプリケーションで実行されるすべての操作に対して一意であることを確認するにはどうすればよいでしょうか?

深い抽象化アセンブリのどこかに、OperationContext.Currentからデータを読み取るWCF動作があります。このコードがタスク内から実行されると、OperationContext.Currentは空になります。これは、抽象化アセンブリ内で解決できますか。このアセンブリのすべてのコンシューマーにコードを追加する必要がありますか？

OperationContext から拡張機能のインスタンスを取得する際に、異なる操作間で相互汚染が発生しているように見える問題を調査しています。これは、レプリケートが困難な同時実行性に基づく煩わしい問題の 1 つです。ある種のスレッドの問題を強く疑っています。IIS7.0/.NET 4 統合モードで WCF サービスを実行しています。拡張機能の関連セクションは次のとおりです。

上記はPostSharpの側面から呼び出されていますが、これが関連しているかどうかわかりませんか? 上記を考えると、 current への呼び出しが間違った CustomContext インスタンスを返す可能性がある明らかな条件はありますか? このようなオープンエンドの質問をお詫びします。

複数のクライアントに接続する WCF サービスがあります。サービスは次のように構成されます。

私が使用するサービスでは、OperationContext.Current.SessionId を使用してクライアントを識別します。

次のシナリオを想像してください: - Client1 が Register を呼び出します - サービスが Thread1 で Register を実行します - 一定時間後に Client2 が Register を呼び出します - サービスが Thread1 でも Register を実行します (これは理論的には可能ですよね?)

OperationContext.Current が ThreadStatic であることを知っていると、2 番目の呼び出しが表示されます。

• セッション 1 は、OperationContext.Current が最初の呼び出しで既に設定されているためです。
• またはセッション 2 ..?

前もって感謝します ...

WCFを使用して、WCFサーバーがWindowsサービス内にあるパブリッシュ/サブスクライブシステムをセットアップしようとしています。バインディングはnet.TCPです。このサービスは、クライアントに「Subscribe」メソッドを提供しているため、クライアントは、サーバーにリンクされたDLLから発生するイベントにコールバックハンドラーを登録できます。Subscribeメソッドで、OperationContext.Current.GetCallbackChannelメソッドを使用してコールバックチャネルを取得しようとしています。これを試みると、OperationContext.CurrentプロパティはNULLを返します。

このプロパティがnullを返す状況を誰かに教えてもらえますか？何かを設定するのを逃したことがありますか？以下にサービスコードとインターフェースコードを含めます。Visual Studio 2012でc＃を使用しており、フレームワーク4.5をターゲットにしています。

サービス：

インターフェース：

クライアント：

** * ** ****新しい 編集 **** ** * ** * ** * ** _ _ _ SalientBrainの提案のおかげで、クライアントが接続されていなくてもサービスが長時間実行され、継続的に実行される必要があることに気付いたため、プロジェクトに大幅な変更を加えました。そのため、シングルトンに変更しました。それでも、私の元の問題はまだ残っています。SalientBrainは私の設定ファイルを見るように頼んだので、他のすべての関連ファイルと一緒にそれを以下に含めます。スペースを節約するためにそれを取り除きましたが、重要なものは何も削除しなかったと思います。PulisherServiceクラスのSubscribeメソッドでエラーが発生します。私はそれが設定ファイルでやった愚かなことだと思います。さて、ここにあります：

構成：

WcfContracts：

WcfService：

WindowsService：

TestForm：

TestCallbackClass：

通常の WCF 要求/応答コントラクトでは、次のようなものを使用してメッセージ ヘッダーを読み取ることができます。

私が理解できないのは、二重契約のコールバック側でこれを行う方法です。コールバック実装の内部OperationContext.Currentはnull.

2013 年 4 月 5 日編集: net.tcp に基づくカスタム バインドを使用していますが、多くのカスタマイズが行われています。たとえば、Xml ではなくプロトコル バッファ メッセージ エンコーディングを使用します。また、いくつかのカスタム セキュリティもあります。

私のプロジェクトには、すべてのメソッドで使用されるメソッド PreAction() があります。PreAction() には Operation コンテキスト オブジェクトが含まれます。

したがって、そのメソッドでメソッド X を呼び出そうとするときは、PreAction() メソッドを使用しています。操作コンテキストがサービス モデルであるため、オブジェクト参照がオブジェクトのインスタンスに設定されていないことを示す例外が発生します。

では、このシナリオをどのように克服するのでしょうか? Mcoking を使用する方法はありますか? このシナリオを解決できますか?

ありがとう！！！

コールバックを介して通信が行われ、InstanceContextMode が PerSession である WCF、tcp ベースのクライアント サーバー アプリケーション (自己ホスト型) があります。管理者が接続されているすべてのユーザーの詳細を表示し、ある程度の管理制御 (セッションの強制切断など) を提供できるようにする、このアプリに管理者インターフェイスを提供したいと考えています。

コールバックを使用しているため、各クライアント プロキシは、コンストラクターを介してサーバーにインスタンス コンテキストを提供します。たとえば、クライアントは次を使用してサーバーへのプロキシをインスタンス化します。

サーバー側では、次を使用してこのコンテキストを取得します。

私の最初の考えは、OperationContext オブジェクトのコレクションを維持する (つまり、接続された各クライアントのコンテキストへの参照を保持する) シングルトン 'SessionAdmin' クラスを実装することでした。新しいクライアント セッションはすべて「SessionAdmin」クラスの同じインスタンスに登録されるため、すべてのクライアント セッションにアクセスできる中心的なクラスが提供されます。

これはある程度機能しますが、「OperationContext」オブジェクトのコレクションにアクセスしてクライアントの詳細を取得したり、他の操作を実行したりするさまざまな時点で、コンテキストが「オブジェクト破棄」例外をスローしていることに気付きます。

私の質問は、まず、上記は WCF セッションに対するサーバー側の管理制御を提供する合理的な方法のように聞こえますか? もしそうなら、それらのオブジェクトを破棄せずにサーバー側でクライアントセッションまたはそのコンテキストのコレクションを維持するにはどうすればよいですか? 問題の例は次のとおりです。