ndb事务内的数据存储实体读取(仅keys_only)

Question

我有一个关于ndb事务中数据存储实体读取的问题。

我知道，当我们在ndb事务中读取一个实体时，这个特定的实体会被锁定，任何其他线程都不能放置/更新/写入同一个实体，因为这会导致争用错误。这完全说得通。

然而，当我们只读取一个实体的键而不是事务内部的整个实体本身时，会发生什么呢？这可以通过在ndb.query()中将keys_only标志设为True来实现。在这种情况下，实体会再次被锁定吗？

Answer 1

一般来说，最好从事务的保证——可串行化——而不是实现细节——在本例中是读/写锁的角度来考虑事务。实现细节(如何执行查询、锁定粒度、锁定的具体内容等)可能会随时改变，但保证不会改变。

对于这个特定的问题，并假设当前在数据存储模式下实现的Fi恢复：为了确保可串行性，事务T1中的仅键查询锁定了查询检查的索引条目范围。如果这样的查询返回了实体E的键K，那么在不同事务T2中删除E的尝试必须删除E的所有索引条目，包括查询锁定范围内的条目。因此在本例中，T1和T2需要相同的锁，两个事务中的一个将被延迟或中止。

请注意，T2 还有其他方式与 T1 冲突：它还可能创建一个与 T1 的查询匹配的新实体（这需要在 T1 的查询锁定的范围内写入索引条目）。

最后如果T2更新（而不是删除）E的方式不需要对T1查询所检查范围内的索引条目进行任何更新（例如，如果查询类似于“从X中选择*，其中a=5”，并且对E的更新不会改变其“a”属性的值），那么T1和T2将不会冲突（这是一种优化——如果这两个事务发生冲突，行为仍然正确，事实上，对于“Datastore Native”数据库，它们可能会发生冲突）。

Answer 2

事务锁的数据存储文档说明：

读写事务使用读取器/写入器锁来强制实施隔离和可序列化性。

它没有提到在交易过程中使用keys_only的细节的任何情况。因此，我认为这同样适用于这种情况，如果您认为您仍在进行读取，那么您只是忽略了数据，这确实是有道理的。

话虽如此，也许这是可以在数据存储中改进的东西，甚至可以在留档中明确说明。如果您愿意，您可以考虑打开一个功能请求，让谷歌通过以下链接来实现它。