1

ASP.NET アプリケーションのクラス ライブラリの一部として Windows ワークフローを使用しています。ASP.NET での WWF の設定と ManualWorkflowSchedulerservice の使用に関するすべての提案を読みましたが、それが私のアプリにとって意味があるかどうかはわかりません。

私のワークフローはすべてシーケンシャルで、持続性はありません。彼らは火であり、忘れます。クライアントは要求を行い、後で結果を確認するために戻ってきます (またはアプリで待機します)。これまで、私は AJAX Web サービス クラスを使用して仕事を開始してきました。

function DoWebserviceJob()
{
   MywebService.DoJob(onComplete, onFailed);
}

[WebMethod]
public DoJob()
{
   //code from library
}

顧客がまだ近くにいれば通知が届きますが、そうでなければ大丈夫でした。現在、ライブラリから直接コーディングする代わりに、WWF を使用しています。私はこれが機能することを知っています（私がそれを行ったので）が、私が気付いていない副作用やその他の懸念があるかどうか疑問に思っています. 私の新しいコードは次のようになります。

[WebMethod]
public DoJob()
{
     WorkflowRuntime runtime = Application["RUNTIME"] as WorkflowRuntime;
     MyWorkflowManager.DoJob(runtime);
}

私のクラス ライブラリ:

public void DoJob(WorkflowRuntime runtime)
{
   WorkflowInstance instance = runtime.CreateWorkflow(typeof(MyWorkflow));
   instance.Start();
}

これは少し単純化されていますが、全体的なプロセスはここにあります。これは今のところ問題なく動作していますが、私が懸念すべき問題はありますか? スレッドの場合 (これが最も懸念されているようです)、これは Web サービスが別のスレッドで起動することと同じではありませんか?

4

1 に答える 1

3

不明な点が多いので、良い答えを出すのは難しいですが、とにかくそれを示します。

ASP.NET と WF で最もよく耳にする問題は、どちらも ThreadPool を使用していて、お互いを認識していないということです。この問題は主に ASP.NET サイトに依存します。既定では、WF は ThreadPool で少数のスレッドのみを使用します (ワークフローを実行するためのプロセスごとに 4 つと、ランタイム用にもう 1 つ)。この問題は通常、WF がホスト スレッド、つまり ASP.NET で使用されるスレッドを使用するため、手動の WF スケジューラを使用することで解決されます。これは、ニーズに応じて良い場合も悪い場合もあります。まず、ThreadPool のサイズが大きくなり、現在は proc あたり最大 250 スレッドであるため、負荷の高い Web サイトでない限り、ThreadPool の枯渇が問題になることはほとんどありません。手動スケジューラを使用することの欠点は、すべてのリクエスト、つまり instance.Start() が同期になることです。リクエストを完了するためにワークフローから何かが必要な場合でも、それが発火してASPを忘れる場合。NET 要求は、ワークフローが終了するか、アイドル状態になるのを待っています。したがって、場合によっては、ASP.NET アプリの既定のスケジューラを使用したほうがよい場合があります。それはすべて、実行内容とサーバーの負荷によって異なります。

覚えておくべきことの 1 つは、IIS が特定の時間 (既定では 25 時間、または要求数) の後に AppDomain をリサイクルすることです。それが発生すると、WF ランタイムが破棄され、次のリクエストで別の AppDomain に再作成されると思います。永続性を使用していない場合、ワークフローの状態はすべて失われ、既存のワークフローは終了します。ワークフローにかかる時間によって、これが問題になる場合とそうでない場合がありますが、私の側からはわかりにくいです。

于 2009-03-29T12:24:02.393 に答える