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