Stored procedures DocumentDb存储过程和乐观并发

我的目标是编写一个存储过程或触发器，允许我在一个事务中读取、替换文档，然后更新元数据文档

现在我知道，如果我按顺序写入集合，这将按预期工作，但如果我并行执行多个存储过程，我是否必须手动配置脚本以比较etag，或者这是服务器端脚本的默认行为

在阅读了一些例子后，我发现如果EATG在读替换操作中间发生变化，事务将自动失败。 然而，在本文中，作者将etag包含在requestOptions对象中，并将其传递到replaceDocument方法中，这与我在客户端使用.NET SDK所做的类似

---

这些前后矛盾使我感到困惑。因此，我的问题是：对于服务器端脚本，是否需要在requestOptions对象中包含etag以强制乐观并发，还是默认行为？

每个脚本作为一个事务运行。由于快照隔离，当两个脚本更新同一个文档时，如果一个脚本更新成功，并且它们都在未更新文档的快照时启动，则另一个脚本将失败，之后另一个脚本将无法更新文档，因为它无法读取文档的版本，如果该版本晚于其快照，脚本必须退出/返回到客户端，客户端必须再次执行脚本。因为使用ETag进行并发保护是没有帮助的。

这是一个好问题。我一直在使用etag（可能是防御性的），这与我的理解相冲突，即每个存储过程都是独立运行的，读和写都没有机会看到不一致的视图，这使我认为没有必要这样做。