交易冲突后重试交易安全吗?
对实体的失败(带有“事务冲突”)写入操作是否会覆盖另一个成功提交的事务上对同一实体所做的更改?
据我了解,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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
是的,如果发生碰撞,整个功能会重新运行。这就是您必须在事务自己的函数中实现事务的原因:因为它们可能需要执行多次。可以保证您的事务更改不会覆盖其他事务更改 - 这就是事务性的全部意义。
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.