ASP.NET AJAXアプリケーションでのWindowsワークフローの使用

Question

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

私のワークフローはすべて順不同です。彼らは火で忘れている。クライアントはリクエストを出し、後で戻って結果を見る（またはアプリを待つ）。今まで私はAJAX Webサービスクラスを使用してジョブを起動していました。

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

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

それはOKだったではない場合、彼は、通知を取得したいの周りに顧客がまだあった場合。現在、ライブラリから直接コーディングする代わりに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(); 
} 

これは少し単純化しているが、全体のプロセスはここにあります。これは今すぐうまくいきます。私は懸念すべき問題はありますか？スレッド（これは最も懸念されているようです）の場合、これは別のスレッドで起動するwebserviceと同じではありませんか？

Answer 1

未知のものがたくさんあるので、あなたには良い答えを与えるのは難しいですが、とにかくそれを表示します。

ASP.NETとWFでよく聞かれる問題は、両方ともThreadPoolを使用しており、互いに認識していないことです。この問題は主にASP.NETサイトに依存しますが、WFはデフォルトでThreadPool内のいくつかのスレッドのみを使用します（ワークフローを実行するためのprocごとに4つ、ランタイムにはもう1つ）。 WFがホストスレッド、つまりASP.NETで使用されているスレッドを使用しているときに、手動WFスケジューラを使用することによって問題は通常解決されます。これは、あなたの必要に応じて良いか悪いかが今ではあります。まず第一にThreadPoolのサイズが増えており、現在は1つのプロセッサにつき最大250のスレッドとなっているため、高負荷のWebサイトでない限りThreadPoolの飢餓が問題になることはまずありません。手動スケジューラを使用することの欠点は、すべてのリクエスト、つまりinstance.Start（）が同期することです。要求を完了するためにワークフローから何かが必要だが、起動していてASP.NETリクエストが忘れていれば、ワークフローが終了するか、または何らかのアイドル状態になるのを待っている。したがって、場合によっては、ASP.NETアプリケーションのデフォルトのスケジューラを使用する方が良いでしょう。すべての作業とサーバーの負荷によって異なります。

IISは特定の時間が経過するとAppDomainをリサイクルしますが、既定では25時間、または要求の数は考えられます。それが起こると、WFランタイムが破棄され、次の要求で別のAppDomainで再作成されます。永続性を使用していない場合は、すべてのワークフロー状態が失われ、既存のワークフローが終了します。ワークフローにかかる時間に応じて、問題が発生する可能性があります。