如何在CosmosDB中围绕SQL API和GraphDB进行分布式事务关联? [英] How to do distributed transaction cordination around SQL API and GraphDB in CosmosDB?

问题描述

我有一个Customer容器，其中的物品表示CosmosDB中SQL API (DocumentDB)中的单个客户.我也有一个包含客户shoppingcart数据的Gremlin API (GraphDB).这些数据都是临时的/暂时的.客户可以选择清空购物车，这将删除临时customer和shoppingcart数据.

I have a Customer container with items representing a single customer in SQL API (DocumentDB) in CosmosDB. I also have a Gremlin API (GraphDB) with the customers' shoppingcart data. Both these data are temporary/transient. The customer can choose clear shopping cart which will delete the temporary customer and the shoppingcart data.

目前，我分别进行调用，分别调用SQL API (DocumentDB)和Gremlin API (GraphDB)，但我想将两者都作为事务来完成(ACID原理).要删除customer，我调用Gremblin API并删除shoppingcart数据，然后调用SQL API删除customer.但是，如果使用SQL API删除客户(第二步)失败，我想回滚在第一次调用中所做的更改，这将回滚已删除的shoppingcart数据.在T-SQL世界中，这是通过commit和rollback完成的.

Currently I make separate calls, one to the SQL API (DocumentDB) and Gremlin API (GraphDB) which works but I want to do both as a transaction (ACID principle). To delete a customer, I call the Gremblin API and delete the shoppingcart data, then call the SQL API to delete the customer. But if deleting the customer with the SQL API (second step) fails, I want to roll back the changes done in the first call which will roll back the shoppingcart data which were deleted. In the T-SQL world, this is done with a commit and rollback.

如何围绕customer和shoppingcart数据的删除操作实现分布式事务协调?

How can I achieve distributed transaction coordination around the delete operations of the customer and shoppingcart data?

推荐答案

由于您在Cosmos DB中没有跨不同集合的事务(

Since you don't have transactions in Cosmos DB across different collections (only within the partition of one container), this won't be directly possible.

下一件最好的事情是使用更改Feed .每当更改或插入项目时，它就会被触发.但是:它不会在删除时触发.因此，您需要"

Next best thing could be to use the Change Feed. It gets triggered whenever an item gets changed or inserted. But: It does not get triggered on deletes. So you need another little workaround of "soft deletes". Bascially you create a flag to that document ("to-be-deleted" etc.) and set its TTL to something very soon. This does trigger then change feed and you can from there delete the item in the other collection.

这一切都比您目前拥有的更好吗?老实说，不是真的，如果你问我.

Is all that better than what you currently have? Honestly, not really if you ask me.

//更新:要添加有关提交/回滚的要点:这在Cosmos DB中也不存在.我想到一种可能的解决方法:

//Update: To add to the point regarding commit/rollback: This also does not exist in Cosmos DB. One possible workaround for this that comes to mind:

1. 更新集合购物车中的元素.将标志to-be-deleted设置为true并将这些元素的TTL设置为now() + 5 minutes
2. 删除customer集合中的元素.如果可行，一切都很好.
3. 如果删除失败，请再次更新购物车.删除to-be-deleted标志并删除TTL，以便Comsos DB不会自动将其删除.

1. Update elements in collection shopping cart. Set a flag to-be-deleted to true and set the TTL for those elements to something like now() + 5 minutes
2. Delete the element in customer collection. If this works, all good.
3. If deletion failed, update the shoppingcart again. Remove the to-be-deleted flag and remove the TTL so Comsos DB won't automatically delete it.

当然，您还需要更新针对购物车运行的所有查询，以排除所有带有删除标记的元素.

Of course, you also need to update any queries you run against your shoppingcart to exclude any elements with the deletion flag in place.

这篇关于如何在CosmosDB中围绕SQL API和GraphDB进行分布式事务关联?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！