Windows 工作流：为什么他们会陷入持久性困境？

Question

我有一个使用 SQL 持久性的 Windows 工作流实例，托管在 Web 运行时中，因为工作流是由 ASP.NET 表单提交启动的。 大多数时候它运行得很好，但我注意到有些情况下我必须踢东西：

我注意到 nextTimer 已经逾期了，甚至逾期了几个小时。 有时，持久性数据库中的ownerID和ownedUntil字段为空，有时则不是。 “解锁”和“阻止”字段始终均为“1”。

...然后工作流运行时不会重新拾取它，直到我清空“所有者”字段（如果它们已填充）并通过回收踢出应用程序池，并且在大多数情况下，事情进展顺利。 没有错误（我在所有内容周围都有 try/catch 块，并将捕获的任何内容写到跟踪文件中），所以不是这样。

导致持久化的延迟活动均设置为一分钟，运行时的所有权持续时间也为60秒。 它被卡住的代码应该总是花费不到一分钟的时间。

当我写这篇文章时，我很好奇应用程序池/应用程序域的回收是否会导致它......当工作流尝试在运行时调用任何方法时，它正忙于旋转应用程序域/池，并且可能会泄漏60 秒所有权持续时间。 这听起来有点合理，这会导致它不能正常补水吗？

除了这个岔路之外，什么可能导致我所看到的这种行为？ 我不想每天通过解除卡住的工作流程来照顾运行时。

Answer 1

应用程序域回收很可能是您问题的很大一部分。 一旦最后一个请求完成，IIS 将回收 AppDomain。 但是，它不会将另一个线程上运行的代码视为该请求的一部分。 这是在 IIS 中托管时使用 ManualWorkflowSchedulerService 的主要原因之一。 但是，当您使用活动计时器选项时，它仍然使用后台线程来执行工作流活动。

还要确保工作流程闲置后立即卸载。 最简单的方法是使用 SqlWorkflowPersistenceService 上的 UnloadOnIdle 设置。

PersistenceService 仅在启动时检查所有权已过期的工作流。 因此，重新启动 IIS 工作进程很可能也会重新启动旧的工作流程，而无需任何额外的工作。 但由于这是新问题的情况......只需清除旧的所有权也应该可以解决问题。 在这种情况下，PersistenceService 应该在下次重新加载工作流程。 唯一的技巧是知道哪个 runitme ID 是旧的，哪个不是（保存该值的属性不是公开的）。

另一件需要确保的事情是 IIS 工作进程已重新加载。 如果不这样做，则没有 WF 运行时，因此它无法检查过期的计时器。 听起来你已经涵盖了这一点，但以防万一。

Answer 2

您是否检查过数据库和网络服务器上的时钟（如果它们不是同一台服务器）？ 我之前在工作流程中遇到过类似的问题，根本原因是数据库和网络服务器时钟不同步。

Answer 3

工作流实例被锁定到运行时（因此多个工作流运行时可以共享数据库，而无需同时处理实例）。 当 AppDomain 回收时，运行时应该停止，导致实例解锁

这可能是多余的，我没有检查这一点，但它有助于解锁工作流实例：

AppDomain.CurrentDomain.DomainUnload += ((sender, args) =>
                                             {
                                                 if (_runtime.IsStarted)
                                                     _runtime.StopRuntime();
                                             });
AppDomain.CurrentDomain.ProcessExit += ((sender, args) =>
                                            {
                                                if (_runtime.IsStarted)
                                                    _runtime.StopRuntime();
                                            });