交易冲突后重试交易安全吗?

发布于 2024-12-10 08:24:29 字数 916 浏览 1 评论 0原文

对实体的失败(带有“事务冲突”)写入操作是否会覆盖另一个成功提交的事务上对同一实体所做的更改?

据我了解,gae 中的事务操作采用快照可串行隔离,但尚不清楚写入倾斜是否可能。

为了简单起见,做一个计数器的坏例子:

def increment_counter(key, amount):
    obj = db.get(key)
    obj.counter += amount
    obj.put()

如果在事务中运行,由于冲突而失败并重试,它会正确更新吗?

重试是否意味着重试整个操作或仅重试提交,或者是否意味着实体组上发生冲突,但此处所做的更改与实体组中的其他更改不冲突 - 因为它们的更改不同实体。

附言。这可能是一个愚蠢的问题,但它让我烦恼这些重试到底是如何应用的。

更新

交易文章是我错过的一条线索。

如果在事务期间更新实体,则重试事务,直到所有步骤完成而不会中断

这是否意味着在事务上下文中运行的整个代码在发生冲突后重新运行?

Can a failed — with "transaction collision" — write operation to an entity overwrite changes made to the same entity on the other successfully committed transaction?

I understand that transactional operations in gae are in snapshot SERIALIZABLE isolation, but it's not clear if write skew is possible.

For simplicity sake a bad example of doing counters:

def increment_counter(key, amount):
    obj = db.get(key)
    obj.counter += amount
    obj.put()

If run in transaction, failed due a collision and re-tried, will it update correctly?

Does retry mean a whole operation gets re-tried or just the commit, or does it mean that collision was on the entity group, but the change made here is not in conflict with other changes in the entity group — cause they where made to different entities.

PS. This maybe a dumb question, but it bugs me how exactly these re-tries are applied.

UPDATE

In the Transactions article is a clue that I missed.

If the entity is updated during the transaction, then the transaction is retried until all steps are completed without interruption

Does this mean that the whole code run in the transaction context is re-run after a collision?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

┼── 2024-12-17 08:24:29

是的,如果发生碰撞,整个功能会重新运行。这就是您必须在事务自己的函数中实现事务的原因:因为它们可能需要执行多次。可以保证您的事务更改不会覆盖其他事务更改 - 这就是事务性的全部意义。

Yes, the whole function is re-run in the event of a collision. This is the reason you have to implement transactions in their own functions: because they may need to be executed multiple times. It's guaranteed that your transactional changes won't overwrite other transactional changes - that's the whole point of having transactionality.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文