C# Windows工作流4.5延迟活动未持久化

我有一个为工作开发的WF4.5服务，它在工作流中使用延迟活动。工作流托管在AppFabric中（在Visual Studio中进行本地测试）。我在服务中设置了web.config，AppFabric设置为使用自定义配置。以下是工作流相关部分的图像：

从图像中可以看出，延迟（确定通信）之前的活动确实在运行，我有可验证的证据。我还知道延迟活动之后的UpdateRejectionInfo不会运行（在运行工作流时，通过自定义活动中的断点进行验证）

我尝试在DetermineCommunication活动和delay活动之间添加一个持久化活动，它确实保存到我正在查找的数据库中，因此我知道该服务具有对数据库的写入权限

以下是该服务的web.config的行为部分：

<behaviors>
  <serviceBehaviors>
    <behavior>
      <sqlWorkflowInstanceStore
        connectionString="SERVER=hq-sql02\oculusdev;Database=EAA;Trusted_Connection=yes"
        hostLockRenewalPeriod="00:00:30"
        runnableInstancesDetectionPeriod="00:00:30"
        instanceCompletionAction="DeleteNothing"
        instanceLockedExceptionAction="AggressiveRetry"
        instanceEncodingOption="GZip"/>
      <workflowIdle timeToPersist="00:00:20" timeToUnload="00:00:30"/>
      <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

---

任何形式的帮助都会令人惊讶。

好的。因此，这个问题的答案远远超出了延迟活动，并涉及到我使用的其他技术，我甚至没有提到这些技术

TL；博士： 我没有将实体框架对象设置为禁用延迟加载。因此，在序列化数据时，抛出了一个我从未见过的异常，它会使工作流崩溃

长版本： 将数据持久化到数据库时，程序会尝试序列化工作流范围中的所有对象。这对于标准C#对象是正常的，但当它们成为复杂对象时，序列化会变得更复杂

为了简化技术，我在项目中使用实体框架（数据库优先）来传递和保存数据库实体。当实体框架实体被序列化时，它们会尝试获取它可用的所有信息。实体框架具有延迟加载数据的思想，因此如果您从数据库中获取实体，并且希望获得更深的层（即通过外键关系），它将返回并查询数据库中的信息。从数据库中获取实体的一种常见方法是获取实体，然后通过使用短期使用块切断数据库连接

如果您决定使用短期使用块（我喜欢称之为单例实体），并且您没有关闭延迟加载，那么当程序尝试序列化实体时，它将开始请求初始请求中未捕获的所有额外数据。如果using块已经退出，数据库连接将不可用，它将抛出异常

我没有捕捉到内置活动抛出的异常，因此它看起来不像是失败的，而实际上是失败的