Workflow Foundation ExternalDataExchange 消息排队和事务性？

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. 工作流不应该对我通过外部数据交换入队的消息做出反应，直到将消息入队的事务被提交（就像 SQL Server 中的服务代理所做的那样）。

--或--

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

Answer 1

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

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

像上面那样使用事务范围很好，但您必须记住，事务范围真正起作用的唯一时间是 using 块中的类知道事务范围。

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

如果您可以详细说明您要在更高级别上实现的目标，那么 WF 的某些内在特性可能比试图将事务范围塞进组合中更适合您。

编辑

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

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

当我遇到这样的问题时，10 次中有 9 次看起来 WF 不支持我正在尝试做的事情，问题是因为我要么保留了太多代码在外面 工作流或试图将太多代码 放入 并重构我的工作完成位置通常可以解决我的问题，而无需我编写新的东西。