代码之家  ›  专栏  ›  技术社区  ›  Petr Felzmann

工作流基础:永不完成的延迟活动

  •  1
  • Petr Felzmann  · 技术社区  · 16 年前

    让我们有一个由接收活动和延迟活动组成的工作流。 接收活动具有 CanCreateInstance = true 并提供了查询(消息)关联。 工作流托管在工作流服务中 并在空闲时立即保存到数据库中。

    WorkflowService service = new WorkflowService
    {
      Name = "MyWorkflow",
      Body = new MyWorkflow(),
      Endpoints =
      {
        new Endpoint
        {
          ServiceContractName = "IMyWorkflow",
          AddressUri = new Uri("http://localhost:1234/MyWorkflow"),
          Binding = new BasicHttpBinding()
        }
      }
    };
    
    WorkflowServiceHost host = new WorkflowServiceHost(service);
    string conn = "Data Source=...;Initial Catalog=...";
    host.DurableInstancingOptions.InstanceStore = new SqlWorkflowInstanceStore(conn);
    host.Open();
    

    现在我将消息发送到工作流 运行时创建第一个工作流实例。 当然,相关键包含在消息中。 工作流继续执行延迟活动 并保存到数据库并卸载。

    假设延迟时间足够长,我将发送下一条消息 具有完全相同的相关键。发生什么事了? 两个工作流都不会从延迟中唤醒,也不会完成。

    我做错什么了? 为什么工作流运行时不保护我不受此影响? 是否有任何方法可以挽救这两个工作流实例?

    谢谢你的帮助!

    1 回复  |  直到 16 年前
        1
  •  2
  •   Maurice    16 年前

    如果使用消息关联,则消息中的键值必须与单个活动工作流匹配。如果尝试使用同一个键启动第二个工作流,则在尝试启动新实例时会出现异常。现在,如果您只使用一个没有sendReply的接收,那么您将创建一个单向消息传递方案,并且无法将SOAP错误发送回客户机。所以客户机可能不知道这个错误。如果在服务中打开跟踪并检查日志文件,仍然可以看到这一点。然而,更简单的选择是包括sendReply,即使您没有正常的响应,因为这会导致包含错误消息的响应消息。