Google App Engine 文档说“事务是数据存储区的一项可选功能；您不需要使用事务来执行数据存储区操作。”。然而，即使是最简单的业务交易也需要更新多个实体类型。在更新这些实体类型之间可能会出现许多问题，从而导致对数据存储的部分更新。因此，与复杂的错误处理机制相比，使用事务似乎是维护数据完整性的最简单解决方案，当更新多个实体类型期间出现问题时，可以逆转数据存储更新。
虽然我了解事务中需要实体组和祖先查询，但它们似乎是不切实际的限制。除此之外，还有跨组交易的限制。
我完全没有抓住重点吗？是否有关于何时应该使用交易的指南？当交易是绝对必要的；何时应该使用错误处理机制来恢复数据存储更改？
【问题讨论】：
标签： google-app-engine transactions
数据存储事务是一种权衡。在事务中更新两个实体时，您可以保证更新将是事务性的：它要么完全成功（应用所有更改），要么完全失败（未应用更改）。作为交换，对实体组的所有更改都是序列化的：如果两个用户同时尝试修改同一个实体组，则第一个成功的用户获胜，第二个用户取消并必须重试。两个用户“竞争”实体组，并且必须放慢更新速度，以便一次只应用一个更改。
如果您将所有实体放在同一个实体组中，您的应用每秒只能进行少量更改。这将无法扩展到数百个并发用户。这就是数据存储允许您在数据模型中定义事务的“位置”的原因。不需要事务性的并发更新可以同时应用在不同的数据存储机器上。
您可以考虑如何以不同的方式为您的实体组建模。您可以从您的观察开始，即您的业务逻辑的理想情况是所有实体都在同一个组中，然后在并发更新有好处并且不需要事务性时开始将您的数据模型分成单独的组。或者，您可以从其自己组中的每个假设实体开始，然后开始识别需要在事务中一起更新实体的情况并相应地对它们进行分组。后一种策略通常更实用，因为没有其他理由将两个实体放在同一个组中，而且当它们没有通过分组明确引入时，更容易不用担心争用问题。
一个好的经验法则是针对特定于用户的数据（只有一个用户或固定数量的用户会更新的数据）可以存在于自己的组中。棘手的情况是多个任意用户可能更新同一个组，并且许多应用程序都有这种情况。有时您必须忍受争用才能获得正确的数据操作。在这些情况下，有一些方法可以改善用户体验，例如通过将原始数据存储事务的强一致性换取在“稍后”时间（可能仅几秒后）执行该事务的最终一致性，例如通过任务队列。
【讨论】：