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 中的几个线程（每个 proc 4 个线程用于执行工作流，另一个用于运行时）。该问题通常通过使用手动 WF 调度程序来解决，因为 WF 然后使用主机线程，即 ASP.NET 使用的线程。现在根据您的需要，这可能是好是坏。首先，ThreadPool 的大小一直在增长，现在每个 proc 最多 250 个线程，因此 ThreadPool 饥饿不太可能成为问题，除非它是一个高负载网站。使用手动调度程序的一个缺点是所有请求，即 instance.Start()，都变得同步。如果您需要工作流中的某些内容来完成请求，但如果它被触发并忘记您的 ASP。NET 请求现在正在等待工作流完成或达到某个空闲状态。因此，在某些情况下，使用 ASP.NET 应用程序中的默认调度程序会更好，这完全取决于您在做什么和服务器负载。

要记住的一件事是，IIS 将在特定时间后回收 AppDomain，我相信默认为 25 小时或请求数。发生这种情况时，WF 运行时将被销毁，并且在我假设的下一个请求中，会在另一个 AppDomain 中重新创建。如果您不使用持久性，您的所有工作流状态都将丢失，现有工作流将被终止。根据工作流程花费的时间，这可能是一个问题，也可能不是，我很难说。

于 2009-03-29T12:24:02.393 回答