私が取り組んでいる問題に対する最良の選択肢について、フィードバックを探しています。
背景を説明するために、私は最近壊れたビジネス アプリケーションを継承しました (私たちのプロジェクトではそれを使用していたので、それを修正する責任がありました)。
現在、タイムアウト エラーを継続的に受け取るアプリケーションの問題があります。他のオブジェクトのステータスに影響を与える可能性のある何かが変更されたときに、他のテーブルのステータス フィールドを更新する一連のストアド プロシージャを呼び出す Web アプリケーションに絞り込みました。
このアプリケーションを完全に見直すことなく、これらのストアド プロシージャをオフロードしてバックグラウンドで実行し、UI に結び付けないことが最善の選択肢であると判断しました。次のようないくつかのオプションを見てきました。
- 実行を処理する別のスレッドを作成します。(まだタイムアウト)
- BackgroundWorker を使用する (まだタイムアウトしますが、明らかにそうすべきではありませんが、BackgroundWorker が終了するまで待機する原因を特定できないようです)
- Stored Proc の実行をジョブに移動し、それを別の SP から呼び出します。(これは機能しますが、一度に 1 つのジョブしか実行できないという制限があり、複数のユーザーがオブジェクトを更新すると、ジョブが開始されないため、例外が発生します)
現在、これらのストアド プロシージャを、すべてのオブジェクトを更新する 1 日 2 回のスクリプトに移動しましたが、これは一時的な修正にすぎません。
私が検討している 2 つのオプションがあります。最適なオプションと思われるものを実装するためのガイダンスを得たいと考えています。
ジョブの使用を続行し、実行中のストアド プロシージャに、ジョブが空になるまでループするデータベース内のアイテムをキューに入れます。実行中のストアド プロシージャは、新しいエントリを追加するときにジョブが実行されているかどうかを確認し、それに応じて動作する必要があります。
Service Broker の使用を検討するように勧められましたが、その使用方法についてはまったく詳しくありません。これらの更新をよりトランザクション的な方法でキューに入れることができるため、全体的なソリューションとしてより優れている可能性が高いことは理解しています。
これらのオプションは両方とも実行可能だと思いますが、2 番目のオプションの実装を理解するには助けが必要です。私のもう 1 つのジレンマは、これらのストアド プロシージャが 45 秒から 20 秒の間どこでも実行されていることです。オブジェクトを変更したユーザーに、更新が行われたことをどのように通知できますか? これは、ユーザー フィールドを「キュー」に追加するだけで、最後にストアド プロシージャに簡単な電子メールを送信させることができるため、ジョブの使用にフォールバックする場所です。
考え、提案？多分私はこれを考えすぎていますか？