Workflow FoundationExternalDataExchange 消息已排队且具有事务性？

Question

我最近一直在 WF 中处理一些基于ExternalDataExchange 的通信。我的理解是，当使用长时间运行的(在本例中为状态机)工作流时，通信是排队的、持久的和事务性的。

我正在使用 SQL Persistence 和标记为“WaitForIdle = true”的 EventArgs。

我假设当我做这样的事情时:

using(TransactionScope scope = new TransactionScope())
{
     IMyEDEService service = wfRuntime.GetService<IMyEDEService>()
     service.MyMethod(wfInstanceGuid, "Here's some data");
     DoSomeDatabaseWork();
} //Dispose causes scope to rollback

我希望我的事件不会在工作流程中触发。不过，它似乎确实已交付，因此这让我相信这不是事务性的。您可以看到在 DoSomeDatabaseWork() 中提交到数据库的数据如何回滚，但向前推进的工作流程可能会很糟糕。

任何人都可以确认这一点吗？如果可以，您是否有解决方法使该消息成为事务性消息？

我真正想要的是以下两件事之一:

1. 在提交将消息排队的事务之前，工作流不应对我通过外部数据交换排队的消息使用react(就像 SQL Server 中的服务代理所做的那样)。

--或--

如果工作流确实开始对我传递的事件起作用，它也应该回滚。不过，我不明白使用默认调度程序如何会发生这种情况。我希望工作流程执行保持异步，因此如果不需要，我不想切换调度程序。

Answer 1

这里出现了几个问题。首先，当您使用 SQL 持久性时，通知事件工作流并让工作流发布事件是持久且异步的，并且工作流的底层管道是事务性的......但不是您想象的那样。

如果事件序列中的某个地方发生了可怕的事情，最终导致您的工作流程转换到新状态，那么工作流程将恢复到尝试该事件之前的状态 - 这使工作流程保持一致的状态因为“处于状态之间”是一个坏主意。

像上面那样使用事务作用域是可以的，但是您必须记住，事务作用域真正起作用的唯一时间是当 using block 中的类知道事务作用域时。

您可以做的是将“MyMethod”的调用包装在 try/catch block 中。当出现问题时，您可以投票支持回滚...但这仍然不会“取消调用”您的 EDES 上的方法。

如果您可以提供一些有关您想要在更高级别上完成的任务的具体信息，那么 WF 固有的一些东西可能比尝试将事务范围强加到组合中更适合您。

编辑

我做了一些挖掘，发现了几个不同的地方，我们被告知没有 API 来操作调度程序工作队列。不幸的是，对我们来说，这意味着我们想要的任何类型的回滚行为都必须自己手动实现。

如果我更多地了解您为何尝试回滚通过 EDES 排队的工作，我也许能够建议一些潜在的架构来完成您的任务，而无需重新发明轮子(事务)。

十有八九，当我遇到这样的问题时，WF 似乎不支持我想要做的事情，问题是因为我在外部保留了太多代码/em> 工作流程或试图在其中放入太多代码，并且重构我的工作完成位置通常可以解决我的问题，而不需要我编写新的东西。