C# 在transactionscope中写入DocumentDb

我正在尝试将DocumentDb写入作为事务的一部分，如下所示-

using (var scope = new TransactionScope)
{
//first transaction

//write to document db

//third transaction
}

我注意到，如果第三个事务失败，documentDb write不会回滚，我仍然可以在集合中看到该文档。第一个事务（本例中为NEventStore）完全回滚。有人知道DocumentDb是否支持TrnasactionScope吗。如果我有一个嵌套事务怎么办

谢谢

编辑： 所以看起来DocumentDb不支持TransactionScope，而且它对它们一无所知。有没有办法使DocumentDb事务成为C#外部事务的一部分？以前有人见过这个用例吗

---

编辑2：按照建议跟进问题和答案

DocumentDB操作独立于

TransactionScope

。一旦操作返回，它就完成了。数据库服务对

TransactionScope

一无所知，也没有以任何方式连接到它

---

当使用服务器端存储过程时，DocumentDB确实有自己的事务作用域。在存储过程中可以有多个数据库调用，如果一切都成功，则在存储过程退出时会有一个隐式提交。如果出现错误并引发异常，则会对存储过程范围内对数据库执行的所有操作执行隐式回滚。

许多SQL用户不知道在事务不可用的情况下该怎么办

<>您应该自己实现补偿逻辑，或者使用Windows工作流基础框架之类的框架。薪酬逻辑与企业集成模式相关。您还可以使用相关ID模式来检查是否完成了大型操作

当需要进行长时间运行的事务时，SQL人员以同样的方式管理大型操作。

---

谢谢！有办法解决这个问题吗？唯一的办法是按照@David的建议使用DocumentDB的存储过程。最好的方法是在应用程序中实现分布式事务回滚时的补偿逻辑。如果在DocumentDB工作完成后外部部分出现故障，则执行补偿操作“回滚”数据库。@RyanCrawCour MSFT回滚操作失败时会发生什么情况？正如@TimGabrhel的问题所暗示的，第一次编写补偿逻辑非常困难，而且随着业务逻辑的发展，几乎不可能进行维护。这就是引入ACID约束的原因。因此，如果您可以摆脱单分区ACID，请使用存储过程。否则，您可能需要考虑DoCTeNDB的替代方案。IMHO，我认为只有当您必须处理超出您控制范围的外部API时，补偿逻辑才是值得的，即使是您编辑的问题，答案仍然与我发布的相同：没有外部事务机制，只有存储过程范围的事务。注意：在得到问题的答案后，改变问题的上下文并不是很好的形式。最好问一个新问题。当然。我将提出一个新问题来探讨这一背景。