【发布时间】：2015-02-12 22:36:00
【问题描述】：
这个问题是关于并发访问 saga 数据的，当 saga 数据持久保存在 Azure 表存储中时。它也是在 Particular 的文档中找到的参考信息：http://docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency
我们注意到，在一个并发执行处理程序的 saga 中，对 saga 数据的修改似乎是在“最后一次将更改发布到 azure table storage 获胜”的情况下进行的。将 NSB 与 Azure 表存储结合用作 Saga 数据持久层时，这是预期的行为吗？
例子：
- Saga Data 中的整数属性，假设当前 = 5
- 5 个命令由这个 saga 中相同处理程序的 5 个实例处理
- 每个命令处理程序都会递减 saga 数据中的整数属性
- 在处理这 5 条消息后，saga 数据中整数属性的最终值实际上可能是 4 - 如果每条消息都由新的 saga 实例处理，可能在不同的服务器上，每个服务器都有一个 saga 数据的副本指示整数属性为 5，将其减为 4，然后备份。我刚刚描述的是一个非常并发的例子，但是如果同时处理 5 条消息中的任何一条，整数很可能大于 0，saga 数据整数属性达到 0 的唯一时间是 5 条命令恰好执行连载。
另外，由于 Azure 表存储支持乐观并发，是否可以像使用 Raven 作为持久性技术时为 RavenDB 启用该功能一样为表存储启用此功能？
如果这不可能，推荐的处理方法是什么？目前，我们正在订阅这样一种范式，即 saga 中可能同时处理多个消息的任何处理程序都不允许修改 saga 数据，这意味着我们对 saga 消息的协调是通过 saga 外部的方式完成的，而不是使用 Saga 数据正如我们最初的意图。
【问题讨论】：
标签： concurrency nservicebus azure-table-storage nservicebus4