Java GAE HDR：在XG事务中，通过键进行的实体检索最终是否一致？

考虑“用于事务”中的第二个示例（“使用命名键更新实体，或者在实体尚不存在时创建实体”）：

现在考虑一下这个场景。多人游戏只允许任何两名玩家进行一场比赛。为了确保这一点，将使用每个玩家的密钥创建一个密钥。此键用作UniqueMatch实体的键

因此，为了创建匹配，需要创建一个XG事务。在本交易中：

我们检查是否已经存在具有该键的UniqueMatch实体。如果使用该键的datastore.get（）调用没有抛出EntityNotFoundException，那么我们知道这两个播放器之间已经存在匹配项，因此我们回滚（）并向播放器显示错误消息

我们放置（）所有需要放置的实体以创建匹配。这包括UniqueMatch实体，以及其他一些实体

然后提交事务

这似乎很有效。然而，我注意到我可以在短时间内创建任意两名球员之间的两场比赛。在很短的一段时间内（实际上，在其中一个测试中长达10-20秒），我对datastore.get（key）的调用会抛出EntityNotFoundException，即使该键已经被放入（）

这似乎是最终的一致性。但是，按键检索的实体是否保证强一致性？该担保是否受XG交易中的担保影响

---

提前感谢，

我认为您看到的问题可能是因为数据存储（通过键或查询）只能在事务的开始处查看数据存储的状态

来自（在隔离和一致性下）：

在事务中，所有读取都反映事务启动时数据存储的当前一致状态。这不包括事务中以前的PUT和DELETE。保证在事务开始时，查询和进入事务时可以看到数据存储的单个一致快照

此外，在事务之外，您将只看到已提交的put（）：

通过查询或GET从数据存储中检索的实体将只看到提交的数据

可能的解决方案：

在事务外部创建UniqueMatch实体（appengine不允许您放置具有相同密钥的实体，因此如果具有相同密钥的实体已经存在，它将抛出异常）。然后，您可以在事务中创建/放置创建匹配所需的其他实体（如果需要）

---

最后，确保在为UniqueMatch创建密钥时，始终以相同的顺序为玩家创建密钥，因为

key（playerA，playerB）=键（playerB，playerA）

这可能是类似的问题。我在评论中弄错了，请看Guido的评论。我还确信，一旦你从.put中拿回一把钥匙，你就可以随时取回物品，但事实似乎并非如此。可能是Memcache。嗯，我不太确定，Guido是专门讨论查询的，而不是通过键进行实体检索。对于查询，我期望最终的一致性（这实际上是正确记录的）。Memcache可能是一种选择，是的。如果我找不到更好的方法，我会研究memcache，谢谢。当然，您确实提到了按键的实体，所以我想我会将讨论链接起来。我会支持你的问题，这很有趣。您是否可以通过让步骤#2仅放置UniqueMatch实体来放弃跨组需求，然后查看是否仍然发生相同的行为？另外，关于10-20秒的延迟，测试是在开发服务器上还是在部署的应用程序中进行的？@IbrahimArief：我将在第2步中尝试将UniqueMatch实体仅放在非Xg事务中，然后与您联系。但这对生产不起作用，因为我们有可能拥有“悬垂”的UniqueMatch实体。关于延迟，这是针对已部署的应用程序的。我无法在dev服务器中复制此内容。谢谢