1

他の場所で述べたように、このコードには競合状態の可能性があります。

    // do stuff with client, catch exceptions
    if (client.State == CommunicationState.Faulted)
    {
        client.Abort();
    }
    else
    {
        // I hope nothing happened since I checked for a faulted state
        client.Close();
    }

...またはそれをしますか？

ステートマシンとして、クライアントがその状態をチェックしてから閉じる試みの間に、どのような状況で障害状態になりますか？数分/時間/日後でも。

サーバーへの接続が失われることを除外するために、次の簡単なテストを試しました。

  • ifステートメントにブレークポイントを設定します。client.State==が開かれているのがわかります。踏む。
  • WCFサーバープロセスを強制終了します。踏む。
  • Client.Close（）は問題なく実行されます。

2番目のテストとして、サーバープロセスを強制終了するのではなく、ReceiveTimeoutが経過するのを待ちました。それから私はもう少し待った。次に、Client.Close（）にステップしました。問題ない。

クライアントは私からの入力なしに障害状態に入ることができますか？そうでない場合、競合状態の可能性は本当にありますか？

編集：おそらくこれはあまりにも一般的ですが、私は一般的なガイダンスを探していました。私がこの質問をした理由は、一部のWeb開発者に、廃止されたWebサービステクノロジの代わりにWCFを使用させる必要があるためです。理想的には、使用できないことを伝えたいのですが、最終的に障害状態をチェックし、閉じるのではなく中止する限り、using使用できます（このアプローチは理解しやすく、採用しやすいと思います-重要なことですが、 try-catch-finallyWCFを開始するときに、学ぶべきことがすでにたくさんあること）。

それから私は競合状態の問題について考え始めましたが、クライアントを閉じることが目的であるため、他の場所で使用されている場合（つまり、プログラム間で共有されている場合や、現在のプログラムのスレッド。）

したがって、問題は残ります。このシナリオで競合状態が発生する可能性はありますか。それを示すコードを誰かに見せてもらえますか？

4

2 に答える 2

0

リンクした投稿は、wxfプロキシクライアントでのステートメントの使用の問題に対するかなり汎用的な解決策について話している。したがって、一般的な条件下では、貼り付けたコードでの競合を想像できる状況がたくさんあります。特に、同じクライアントを共有するマルチスレッドの状況。

于 2012-04-13T22:35:24.950 に答える
0

満足のいく答えがないため、MSDNソリューションは次のことを行う必要があります。

try
{
    ...
    client.Close();
}
catch (CommunicationException e)
{
    ...
    client.Abort();
}
catch (TimeoutException e)
{
    ...
    client.Abort();
}
catch (Exception e)
{
    ...
    client.Abort();
    throw;
}
于 2012-05-11T17:26:51.563 に答える