我对两种不同的情况有疑问。
方案1： 当前，我们遵循冲突前后查询检查的模式，以维护文档的状态。简而言之， 我们的SP具有以下模式，
问题 1.在冲突后检查之后但在事务提交之前可以更改文档A吗？ 如果是，缓解此问题的最佳方法是什么？
方案2： 我们希望锁定文档以防止进行任何编辑或允许部分编辑。
问题
触发器作为锁 我们可以通过创建一个单独的LOCK文档来实现锁定（由于所有类型的文档只能具有唯一的ID，因此每个文档只有一个锁）。 如果要更改/替换特定文档，我们可以有一个执行并检查锁的预触发器。
使用触发器进行锁定（从性能角度来看）的利弊是什么？ 可以使用前置和后置触发器替换上述方案1 吗？
更确切地说，是在提交“替换”文档调用之后还是之前，触发了“ 帖子”触发？
答案 0 :(得分：0)
这两个问题的答案都可以在这里找到：https://docs.microsoft.com/en-us/azure/cosmos-db/database-transactions-optimistic-concurrency。
场景1：
以为我没有尝试过，但是对于您的第一种情况，我相信您可以在Cosmos DB中使用Stored Procedures。假设两个文档都在同一分区中，则将文档A和B都传递给存储过程。在那里，您将创建文档B。创建文档B之后，您将检查A的状态。如果A不在所需的状态（S1），则将引发异常，并将回滚整个事务。
方案2：
因为这样的锁在Cosmos DB中不可用，但是您可以通过在Cosmos DB中使用Optimistic Concurrency来完成您想做的事情。这是通过使用文档上的_etag属性来完成的。乐观并发可以防止写者在多写者场景中意外覆盖另一写者所做的更改。