当 Firestore 数据存储发生冲突时，事务行为是否发生了变化？

Question

我创建了新的 Google Cloud Platform 项目和 Datastore。

Datastore 被创建为“Datastore 模式下的 Firestore”。

但是，如果发生冲突，我认为 Firestore 数据存储和旧数据存储的行为会有所不同。

例如以下情况。

procA: -> enter transaction -> get -> put -----------------> exit transaction
procB: -----> enter transaction -> get -> put -> exit transaction

旧数据存储；

• procB 已完成，数据已更新。
• procA 发生冲突，数据已回滚。

Datastore 模式下的 Firestore；

• procB 在退出事务之前等待，直到 procA 完成。然后发生冲突。
• procA 已完成，数据已更新。

是规格吗？ 我在 Google Cloud Platform 文档中找不到文档。

Answer 1

我一直在考虑，我认为更改实际上可能是故意的。

在您基本上描述的旧行为中，较短的事务即使在较长的事务之后开始，也会成功，抢占较长的事务并导致它失败并重试。实际上，这会优先处理较短的事务。

但是想象一下，您有一堆较短交易的活动高峰 - 它们将继续抢占较长的交易，这些交易将继续重试，直到最终达到最大重试限制并永久失败。由于重试，还会增加过程中的数据存储争用。我实际上在我的事务繁重的应用程序中遇到了这种情况，我不得不调整我的算法来解决它。

相比之下，新行为使所有交易都有公平的成功机会，无论其持续时间或活动水平如何 - 没有优先处理。确实，以一定的价格 - 较短的交易在较长的交易之后开始并且重叠它们将需要更长的时间。恕我直言，新行为比旧行为更可取。

Answer 2

我建议您查看文档Transactions and batched writes。在本文档中，您将能够找到有关如何使用 Firestore 执行事务的更多信息和示例。

在上面，您会发现更多关于get()、set()、update() 和delete() 操作的说明。

我可以从文档中为您突出显示以下内容，这是您在处理交易时要注意的非常重要的内容：

• 读操作必须先于写操作。
• 如果并发编辑影响事务读取的文档，则调用事务的函数（事务函数）可能会运行多次。
• 事务函数不应直接修改应用程序状态。
• 客户端离线时事务会失败。

如果这些信息对您有帮助，请告诉我！