2

WCFサービスで次の実行チェーンがあるとします。

ServiceMethodはMethod1を呼び出して待機し、次にMethod2を呼び出して待機します。Method2はMethod3を呼び出して待機します。最後に、ServiceMethodはMethod4を呼び出して待機してから、戻ります。

メソッド3(またはこれらのメソッドのいずれか)の実行中にサービスの構成済みタイムアウトが発生した場合はどうなりますか?ServiceMethodを実行しているスレッドはすぐに終了しますか?それ以上の実行はありませんか?または、プロセスにより、結果を返さずにスレッドを最後まで続行できますか?

私の懸念は、タイムアウトが発生する前に処理がどこまで進んだかを知ることです。スレッドの完了が許可されている場合は、(結果が返されない場合でも)とにかくすべてが完了したことを知ることができます。ただし、スレッドがすぐに終了する場合は、ServiceMethodを設計して、スレッドがどこまで到達したかを追跡し、そこから再試行する必要があります。

4

2 に答える 2

3

操作はサーバー上で完了するまで実行できます。タイムアウトになるのは WCF チャネルです。実際、タイムアウトが発生したときにサーバー側の処理を強制的に中止する方法をここで求める人もいますが、それをきれいに行うのは難しいというのが一般的な意見です。

WCF がサービス側のタイムアウトをサポートしないのはなぜですか?

于 2013-02-04T19:57:16.530 に答える
0

ホストによってサービス インスタンスが作成された後、プロセスが終了するか、ロジックが完了してエントリ ポイント (操作) を終了するか、キャッチされない例外がスローされるまで、サービス インスタンスは実行され続けます。あなたが懸念しているタイムアウトは、クライアントとホストの間です。

クライアントは、チャネル障害としてタイムアウトを通知するチャネルで例外を受け取ります。これは、チャネルが安全に使用できず、再作成する必要があることをクライアントに伝えます。

呼び出しチェーンに関する小さなコメント。ステップバイステップのロジックを単一のワークフローまたはマネージャーにカプセル化することをお勧めします。これにより、再開可能性または補償ロジックの要件に役立ちます。ワークフローを実行できる単一のエントリ ポイントをサービスに用意します。

WCF が「500 内部サーバー」からのサービス側のタイムアウトをサポートしない理由の回答に +1

于 2013-02-04T20:07:26.260 に答える