Workflow foundation 4 为什么不'；Windows工作流是否在服务器重新启动后继续？

我有一个简单的Windows Workflow 4.5工作流（文章末尾的屏幕快照），作为IIS中的WCF服务托管。我已经使用Microsoft提供的SQL Server存储设置了持久性

工作流接受文档ID和布尔值，指示是否需要暂停并等待人工活动（由人工审核）。如果工作流需要等待，它会有一个Receive（）活动，该活动与文档ID关联并暂停（这会在后台创建书签）。否则，它将运行到完成并发送文档

只要我们不重新启动服务器，也不做任何类似于为服务回收应用程序池的事情，一切都能正常工作。正如我所理解的持久化，工作流应该在可配置的“空闲时间”之后持久化，例如在等待接收消息时遇到的情况。。。我已将此值设置为非常激进的1秒

但是，在现实世界中，如果您希望长时间运行工作流，如果我们通过重新启动或回收应用程序池来模拟服务器崩溃，则使用Receive（）等待的工作流将永远不会响应。在服务器恢复后，我们是否应该做一些特殊的事情来“重新水化”工作流？关联对持久化的工作流不起作用吗

在以下工作流中，在服务器重新启动后从不激发的Receive（）将以黄色突出显示：

---

我想我找到了这个问题的答案

当您在Visual Studio 2013中创建WCF Worflow应用程序时，它会以一个模板应用程序启动，该模板应用程序包含预连线的Receive（）和Send（）活动。正是这个receive（CanCreateInstance设置为true）允许在收到WCF消息时实例化工作流

问题似乎在于，将接收和发送捆绑在一起，被认为是一项必须在工作流空闲之前完成的操作。也就是说，即使我在工作流中调用了第二个Receive（），并且Receive确实创建了一个书签并导致工作流等待输入，但它实际上不能进入空闲状态。不处于空闲状态意味着工作流无法持久化

您可以在我上传的工作流快照末尾看到Send（）悬空。我将此发送出去，工作流现在可以完美地等待、持续、关联和恢复

---

现在回想起来，我认为我错误地认为预连线发送是为了提供有关工作流的一些信息，而实际上，将其视为对启动工作流的消息的回复是有意义的，仅此而已。通过在Visual Studio作为模板提供的初始Receive（）和成对Send（）之间插入工作流逻辑，我无意中阻止了工作流的空闲，因为Receive/Send似乎被认为是一个原子操作——至少就空闲/持久化而言。

您试图描述的行为“原子”在WF中称为非持久区域。例如，请参阅或