Firestore Datastore模式与旧版Datastore冲突时事务行为差异是否为规范？

没错，你观察到的这种事务冲突行为差异完全是官方的设计规范，只是相关说明确实比较隐蔽，容易在文档里错过。

两种模式的核心并发控制差异 #

• 旧版Datastore采用乐观并发控制：事务全程不会给目标实体加锁，仅在提交瞬间检查数据是否被其他事务修改。所以在你的场景中，procB先完成提交，数据已被更新，procA提交时检测到冲突触发回滚。
• Firestore in Datastore mode调整了逻辑，采用短时效悲观锁机制：当事务（如procA）读取并准备修改某实体时，会临时持有该实体的锁，后续尝试修改同一实体的事务（如procB）会进入等待状态，直到前一事务结束。procA提交完成后，procB再提交时发现数据已变更，从而触发冲突回滚。

文档中的相关线索 #

Google官方文档在介绍Firestore in Datastore mode时，重点强调了其API对旧版Datastore的兼容性，但这种底层并发控制的调整，通常隐藏在「事务高级特性」或「迁移注意事项」的细节章节中。你可以重点查看事务冲突处理、并发控制相关内容，其中会提到这种行为变化是为了减少特定场景下的冲突重试次数，优化部分业务的稳定性。

如果你的业务逻辑依赖旧版的事务冲突行为，可能需要调整重试策略或重构事务设计，以适配Firestore in Datastore mode的特性。

内容的提问来源于stack exchange，提问作者stack_user