我正在尝试使用Google App Engine（高复制数据存储区） 我知道频繁写入单个实体组可能会导致争用。 正是为了避免这种情况发生，我的实体都是根实体，即每个实体都是一个独立的实体组。
我开始交易
获取实体
如果已存在则回滚事务
否则放置实体并提交交易
所以我认为我正在利用app引擎声称的非相关实体（即不在同一实体组中的实体）的高吞吐量强度
然而，有时在看跌期权，我得到了可怕的例外'对这些实体的过多争论'。为什么不应该对不属于同一组的实体进行争用？
我们被告知，对于单个实体组，我们可以预期每秒不会超过1到10次写入。
但是我还没有看到一个数字，我们可以期待app引擎处理写入单独的实体组 这种争论似乎发生在我认为非常低的要求（每秒大约100次写入）
我错过了什么吗？除了拥有单独的实体组之外，还有其他规则要符合以获得高吞吐量吗？
或者我对每秒至少几百次写入的期望太高了？
答案 0 :(得分：1)
你的pseduo代码看起来是正确的。
你也是正确的，非相关的根实体插入应该可以防止争用。
我正在一个请求中更新多个根实体，因此不会有另一个请求同时修改与我的请求相同的数据
但是在txn中有5个实体组限制。 what can be done in txn
解决您的解决方案
-lp
答案 1 :(得分：0)
您的第一个错误是使用实体组。它们根本不是为了避免争用。它是确切的opossite。您无法经常更新实体组中的项目，请参阅文档。实体组对于一致读取而非争用或速度非常有用。
答案 2 :(得分：0)
不确定如何删除答案，因此我正在编辑此答案。
异常的getMessage返回“太多争用”消息。但异常的类是ConcurrentModification。
我正在一个请求中更新多个根实体，因此不会有另一个请求同时修改与我的请求相同的数据
所以我不明白这个'争论'来自何处。
似乎单个请求与自己'竞争'！
一个想法是，由于put的异步性质，然后第一个操作在后来的操作出现之前还没有完全完成？
由于这些是独立的实体组，我认为这些问题必定是由“平板电脑拆分”等引起的。如果是这种情况，我认为将所有这些故障作为ConcurrentModification异常呈现给调用者是一种遗憾。我认为能够区分由于数据存储区中的内部进程导致的失败操作以及更常见的问题（例如另一个用户在您之前修改了数据）