firestore datastore 发生冲突时事务行为是否改变？

Question

我创建了新的 Google 云平台项目和数据存储。

数据存储创建为 "Firestore in Datastore mode"。

但是，我认为如果发生冲突，Firestore Datastore 和 Old Datastore 的行为会有所不同。

例如以下案例。

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

旧数据存储；

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

Datastore 模式下的 Firestore；

• 在退出事务之前等待 procB，直到 procA completed.Then 发生冲突。
• procA 完成并更新数据。

有规范吗？ 我在 Google 云平台文档中找不到文档。

Answer 1

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

在上面，您将找到有关 get()、set()、update() 和 delete() 操作的更多说明。

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

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

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

Answer 2

我一直在考虑，我认为这个改变实际上可能是有意的。

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

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

相比之下，新行为为所有交易提供了公平的成功机会，无论其持续时间或 activity 的级别如何 - 无优先级处理。的确，这是有代价的——较短的交易在较长的交易之后开始，并且将它们重叠，总体上需要更长的时间。恕我直言，新行为优于旧行为。