在Firestore数据存储区中发生冲突时，交易行为是否已更改？

Question

我创建了新的Google Cloud Platform项目和数据存储。

数据存储被创建为“数据存储模式下的Firestore”。

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

例如以下情况。

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

旧数据存储区；

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

数据存储模式下的Firestore；

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

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

Answer 1

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

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

但是，假设您的交易高峰期是一堆较短的交易-他们将继续抢占较长的交易，直到最终达到最大重试限制并永久失败为止，这些交易将被重试。由于重试，还会增加数据存储争用的过程。实际上，我在需要大量交易的应用程序中遇到了这种情况，我不得不调整算法以解决该问题。

相比之下，新行为为所有交易提供了相当大的成功机会，无论其持续时间或活动水平如何-都没有优先处理。的确，要付出一定的代价-较短的交易是在较长的交易之后开始的，而重叠交易将花费更长的时间。恕我直言，新行为优于旧行为。

Answer 2

我建议您看一下文档Transactions and batched writes。在此文档上，您将能够找到有关如何使用Firestore进行交易的更多信息和示例。

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

我可以为您突出显示文档中的以下内容，这对于您在进行事务处理时要注意非常重要：

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

让我知道信息是否对您有所帮助！