如何在CosmosDB中处理事务-“全有或全无”概念

时间:2019-04-01 04:10:19

标签: spring-boot azure-cosmosdb

我正在尝试一次将多个文档保存到“多个集合”中。因此,如果保存之一失败,则所有保存的文档都应回滚

我正在使用SpringBoot和SpringData,并使用MongoAPi连接到Azure中的CosmosDB。我在他们的门户网站上已经读到,可以通过编写一些存储过程来完成此操作。但是有什么办法可以像Spring那样使用@Transaction批注那样从代码中做到这一点?

我们非常感谢您的帮助。

2 个答案:

答案 0 :(得分:0)

只能以事务处理方式编写的 方法是使用存储过程。但这对您的情况没有帮助:

  • 存储过程特定于核心(SQL)API;它们不适用于MongoDB API。
  • 交易的作用域是单个集合中的单个分区。无论您使用MongoDB API还是核心(SQL)API,您都无法跨集合进行事务性写入。

您真的需要问交易是否绝对必要。也许您可以使用某种类型的持久消息方法来管理您的内容更新。但是,根本没有内置功能可以让您在Cosmos DB中本地执行此操作。

答案 1 :(得分:0)

确实不支持跨分区和集合的事务。如果确实需要回滚机制,那么检查事件源模式可能是值得的,因为这样您就可以捕获事件而不是更新主实体。这些事件可以轻松删除,但是其他进程可能仍使用不正确的事件执行。

我们创建了一种工作单元。我们注册对数据模型的所有更改,包括正在发送的事件和消息。仅当我们调用committ时,更改才会按以下顺序保存到数据库:

  • 提交更新
    • 提交删除
    • 提交插入
    • 发送消息
    • 发送事件

尽管如此,它并不是不漏水的,但是只要调用过程尚未准备好(即由于错误),它就可以避免向数据模型发送消息/事件/修改。此UnitOfWork通过我们的域服务传递,以允许我们批处理命令的所有操作。然后,由开发人员决定是否可以将某个操作作为更大的操作(相同的UoW)或独立的(新的UoW)的一部分来提交。

然后,我们将命令处理程序包装在Polly策略中,以在发生更新冲突时重试。从理论上讲,虽然我们可能在第二次更新中遇到更新冲突,这可能会导致数据模型不一致,但是在使用UoW时,请牢记这一点。 它不是水密的,但希望能有所帮助!