1

クライアント アプリケーションは、サーバー上でプロセスを開始します (RIA 経由ですが、実装は重要ではありません)。プロセスとは、ビジネス コードが実行されていることを意味し、CPU で実行されている実際のプロセスを指しているわけではありません。

コードはC#です。

次に、クライアントはプロセスのステータスを確認します。失敗、完了、まだ実行中。

基本は比較的簡単に実装できます。クライアントが定期的にサーバーをポーリングして、プロセスIDに関連付けられたステータスをチェックするプロセスをチェックできるサーバーにプロセスIDを静的に保存します。

このあたりのエッジ ケースには、もう少し作業が必要です。コードが例外を処理せずにスレッド (プロセス) を異常終了させ、プロセスに関連付けられたステータスを正常に失敗に設定する、致命的および壊滅的な理由。このシナリオでは、クライアントはプロセスがまだ進行中であると想定し続けます。

別のスレッドでプロセスを実行し、スレッド ID を追跡することを考えていました。クライアントがサーバーを呼び出してプロセスの状態を確認する場合、プロセスを実行しているスレッドの IsAlive プロパティを確認できます。

これが問題になる可能性のあるシナリオがあるかどうか疑問に思っていますか? スレッドがハングしていても、IsAlive が True を返す可能性があるかもしれません。

別のアプローチは、サーバー上のプロセスに、クライアントが状態をチェックするときに使用できるタイムスタンプを定期的に設定させることです。状態をチェックするコードは、タイムスタンプがどれくらい古いかを確認し、選択した間隔 (たとえば 2 分) に基づいて、プロセスがまだ実行されているかどうかを判断できます (最後にタイムスタンプが書き込まれてから 2 分経過していない)、またはプロセスは例外なくタイムアウトしました (スレッドが最後のタイムスタンプを書き込んでから 2 分以上経過しました)。すべてのタイムスタンプはメモリ内で行われます。

これに関して有益なベスト プラクティスはありますか? これに最善のアプローチをする方法について、特別な洞察やヒントを持っている人はいますか? 私はまた、人々が持っている他のシナリオやアイデアを受け入れることができますか?

4

1 に答える 1

0

より良いアプローチは、各ビジネス プロセスの例外を含むすべてを処理し、すべての状態を維持する、完全に制御されたサーバー アプリを用意することだと確信しています。クライアントがポーリングではなく StateChanged イベントを受信した場合 (たとえば、WCF デュプレックス チャネルを使用) はさらに優れています。あなたがやっていることは基本的に1999年です。.NET では、すべての機能がほぼ無料で提供されます。アーキテクチャを修正することで、実際に書くのが速くなり、時間内にサポートするのが安くなります。

于 2012-06-21T22:55:43.607 に答える