如何通过通用方式处理 Cosmos DB 存储过程中的乐观并发？

Question

我有存储过程，它只是根据 Etag 更新文档。

我已经获取了 3 种类型的文档，更新了所有 3 种文档的一些属性。我正在尝试更新存储过程中的所有 3 个文档。但是在存储过程更新第三个文档之前，另一个用户更新了第三个文档。所以在这种情况下，我确实遇到了并发错误。我可以在存储过程中获取文档，但我不确定我必须更新哪个属性，因为我不知道我或存储过程中的其他用户修改了哪个属性，因为它只是替换了文档。在文档需要更新的任何地方都使用相同的存储过程，因此我无法对其中的属性进行硬编码。

我该如何处理？

在实体框架代码优先方法中，我们确实为 SQL 提供了一个 DbUpdateConcurrencyException 类，从中我们可以看到哪个属性得到修改并相应地采取行动。 Cosmos DB 中是否提供了类似于 DbUpdateConcurrencyException 的异常类？

我确实阅读了DocumentDB revisited Part 3 – Concurrency in DocumentDB 和DocumentDB – Optimistic Concurrency in a Stored Procedure 这两篇文章。它们告诉我们如何使用 Etag 处理乐观并发。

Answer 1

如果您的存储过程只存储新文档，则您无法识别哪些属性已更改。

如果您的存储过程同时使用现有文档（例如，ETag 的版本）和要存储的新文档，那么您可以进行比较以确定哪些属性已更新。当 ETag 检查失败时，使用内存中的差异重新获取最新文档并根据需要更新属性。