何年も前に、「マルチスレッドっぽい」クライアント/サーバー レポート生成システムを作成しました。
これは、VB6、SQL Server 7、Crystal Reports 7、および NT4/Win2K/Win98 が混在する MSMQ に基づいていました。
サーバー上で複数のEXEが実行され（マルチスレッド風）、クライアントからのラウンドロビン要求をリッスンして、レポートを生成し、メッセージをクライアントマシンのトレイアプリに送り返しました。
MSMQ のサポートが面倒になり、クライアント マシンでのシングル スレッド レポート用に MSMQ を捨てるまで、これはすべて非常にうまく機能していました。
今、私たちは現代の技術を使ってそのシステムを作り直さなければなりません。
そう：
- SQL Server 2005 以降
- Win Server 2003 以降
- .NET 3.5 (はい、知っていますが、それほど最新ではありません)
- 「Web フロント エンド」 (複数のサーバー上ではありますが、すべての IPC がサーバー側であるため関係ありません)
- クリスタルレポート 10.5
さて、ほとんどの場合、難しいことは何もありません。
しかし、MSMQ にやられてしまった後は、何百もの異なる顧客の IT ポリシーによってサポートが不可能になることなく展開できるものを求めています。
この位置でのデフォルトのフォールバックは単純です。SQL Server を使用して、ジョブのリストとそれらのジョブの状態を保存します。
ジョブを保存するための「ReportLog」テーブルが用意できました。これに状態フィールドを追加するだけで済みます。おそらく次のとおりです。
- 実行中 (ビット、null 以外)
- 完全 (ビット、null 以外)
それは愚かで単純ですが、うまくいきます。
私の愚かな解決策
では、テーブルを監視するスレッドが 1 つある Windows サービスを構築し、新しいジョブが現れるたびにスレッド プール ジョブを生成します。各スレッドは、その単一のレポートを完了すると OK またはエラーを返し、終了します。
クライアントはログ テーブルをスキャンして、ジョブが完了するのを監視します。
利点:
- 常に機能し、IT 部門が邪魔することはありません
- 単純なことだ、誰もがそれを理解するだろう
- 追加のテクノロジーや構成はありません。(MSMQ には常にインストールと構成が必要です)
短所:
- クライアントはサービスのステータスを認識していません。
- クライアントとサーバーの両方が常にテーブルをポーリングする二重パッシブです
- 複数のサーバーが起動されている場合、それらは二重レンダリング レポートを開始します
- 私が考えることができる（3）の唯一の解決策は、テーブルに対するある種の排他的書き込みロックです（ヤッ！）
- 丸い穴に四角いペグのような感じで、解決策というより回避策です。IMO これはデータベースの目的ではありません!
質問 1: My Dumb Solution が良いアイデアである場合、どのようにすれば Disadvantage(4) を防ぐことができますか?
質問 2: まじめな話、MSMQ と SQL Server テーブルのポーリングよりも優れた方法はありませんか? 少なくともアドバンテージ(1)と(3)があるもの