DevForce リクエストがタイムアウトすると、自動的に再試行されることがわかりました。この動作は、こちらのフォーラムでも言及されています。そのフォーラムの投稿で提案されている解決策は、タイムアウトを増やして問題を完全に回避することです。私たちにとって、それは本当に可能な解決策ではありません。タイムアウトになることがわかっている操作がいくつかあり、タイムアウトを増やすことは受け入れられる解決策ではありません。
さらに悪いことに、呼び出しがストアド プロシージャ クエリまたは InvokeServerMethod 呼び出しである場合、呼び出しがべき等でない可能性が非常に高くなります。したがって、再試行は安全ではなく、結果的に害を及ぼす可能性が非常に高くなります。アプリでそのようなケースが発生し始めており、大きな問題を引き起こしています。簡単な例は次のとおりです。アイテムのコピーを作成するストアド プロシージャを呼び出します。コピーに時間がかかりすぎると、再試行が繰り返されますが、これは、3 つのコピー操作がすべて並行して行われていることを意味します。最終結果は、エンド ユーザーがエラーを受け取ることです (3 回目の rety がまだタイムアウトするため) が、(最終的に) アイテムの 3 つのコピーが存在します (ストアド プロシージャは最終的に終了します - 再試行ロジックは、以前のリクエスト - そのようなキャンセルが可能かどうかさえわかりません)。これはより良性の例の 1 つです。別のケースでは、再試行された操作がさらに悪い問題を引き起こす可能性があります。
6.1.6 リリース ノートから、 DevForceが保存の自動再試行を実行しなくなったことがわかります。その動作が StoredProcedureQueries と InvokeServerMethods に拡張されることを本当に望んでいます。通常の EntityQuery 操作 (およびおそらく Connect/Disconnect 呼び出しでさえ) では、rety で問題ありません。これが DevForce のコアで変更できるものではない場合、構成可能にする方法や、これを制御するコードを挿入するためのカスタム方法を提供する方法はありますか?