DocumentDb 存储过程和乐观并发
DocumentDb stored procedures and optimistic concurrency
我的目标是编写一个存储过程或触发器，允许我读取替换文档，然后在一次事务中更新元数据文档。
现在我知道，如果我按顺序写入集合，这将按预期工作，但如果我并行执行多个存储过程，我是否必须手动配置脚本来比较 etag，或者这是默认行为对于服务器端脚本？
在阅读 this article 中的一些示例后，我的印象是如果 etag 在读取替换操作的中间发生更改，事务将自动失败。
然而，在 this example 中，作者将 etag 包含在 requestOptions 对象中，并将其传递给 replaceDocument 方法，这与我在客户端使用 .NET SDK 时的做法类似。
这些不一致让我感到困惑。所以我的问题是：对于服务器端脚本，是否有必要在 requestOptions 对象中包含 etag 以强制执行乐观并发，或者这是默认行为？
每个脚本作为一个事务运行。由于快照隔离，当两个脚本更新同一个文档时，如果一个更新成功，并且它们都在文档未更新时从快照开始，则另一个将失败，之后另一个将无法更新文档，因为它无法读取文档的版本，如果晚于它的快照，脚本将不得不 exit/return 到客户端，客户端将不得不再次执行脚本。因为使用 etags 进行并发保护是没有帮助的。
我的目标是编写一个存储过程或触发器，允许我读取替换文档，然后在一次事务中更新元数据文档。
现在我知道，如果我按顺序写入集合，这将按预期工作，但如果我并行执行多个存储过程，我是否必须手动配置脚本来比较 etag，或者这是默认行为对于服务器端脚本？
在阅读 this article 中的一些示例后，我的印象是如果 etag 在读取替换操作的中间发生更改，事务将自动失败。 然而，在 this example 中，作者将 etag 包含在 requestOptions 对象中，并将其传递给 replaceDocument 方法，这与我在客户端使用 .NET SDK 时的做法类似。
这些不一致让我感到困惑。所以我的问题是：对于服务器端脚本，是否有必要在 requestOptions 对象中包含 etag 以强制执行乐观并发，或者这是默认行为？
每个脚本作为一个事务运行。由于快照隔离，当两个脚本更新同一个文档时，如果一个更新成功，并且它们都在文档未更新时从快照开始，则另一个将失败，之后另一个将无法更新文档，因为它无法读取文档的版本，如果晚于它的快照，脚本将不得不 exit/return 到客户端，客户端将不得不再次执行脚本。因为使用 etags 进行并发保护是没有帮助的。