特定的NServiceBus Sagas：Azure表存储中持续存储Saga数据的并发访问

Question

当Azure数据存储在Azure表存储中时，此问题与并发访问saga数据有关。它也是特定文档中的参考信息：http://docs.particular.net/nservicebus/nservicebus-sagas-and-concurrency

我们已经注意到，在同时执行处理程序的单个saga中，对saga数据的修改似乎在＆＃34;最后一个用于发布对azure表存储获胜的更改＆＃34;场景。将NSB与Azure Table Storage结合使用作为Saga数据持久层时，这是否是预期的行为？

示例：

1. Saga Data中的整数属性，假设它当前= 5
2. 5个命令由此saga中相同处理程序的5个实例处理
3. 每个命令处理程序都会减少saga数据中的整数属性
4. 在处理这5条消息后，saga数据中整数属性的最终值实际上可能是4 - 如果每条消息都由saga的新实例处理，可能在不同的服务器上，每个都有一个saga数据的副本，表示整数property为5，将其减少为4，并重新发布。我刚刚描述的是非常并发的例子，但如果同时处理5个消息中的任何一个，则整数可能大于0，saga数据整数属性达到0的唯一时间是5个命令碰巧执行的时候串联。

此外，由于Azure表存储支持乐观并发，当Raven用作持久性技术时，是否可以为表存储启用此功能，就像启用RavenDB一样？

如果无法做到这一点，建议的处理方法是什么？目前我们正在订阅这样的范例，即传统中任何可能同时处理多个消息的处理程序中的任何处理程序都不允许修改saga数据，这意味着我们的saga消息协调是通过saga外部的方式而不是使用Saga Data来完成的。正如我们最初想要的那样。

Answer 1

使用特殊支持后 - 上述症状最终成为NServiceBus.Azure的缺陷。这个问题已在NServiceBus.Azure 5.3.11和6.2+中特别修补。我个人可以确认更新到5.3.11解决了我们的问题。

作为参考，这个问题的一个告诉标志表明自己被抛出并且没有被处理的以下异常。

  

无法处理邮件   Microsoft.WindowsAzure.Storage.StorageException：意外响应   操作代码：0

异常的详细信息将表明＆＃34; UpdateConditionNotSatisfied＆＃34; - 参考乐观并发检查。

感谢Special的Yves Goeleven和Sean Feldman诊断和解决这个问题。

Answer 2

azure saga storage persister使用乐观的concurency，如果多个消息同时到达，最后一个要更新的消息应该抛出异常，重试并重新生成数据。

所以这听起来像个错误，你能分享一下你的版本吗？

PS：去年我们已经解决了一个与此https://github.com/Particular/NServiceBus.Azure/issues/124非常相似的问题，它已在NServiceBus.Azure 5.2及以上版本中得到解决