为什么 IndexedDB 被设计为带有锁定表的异步 API？
我的理解是异步部分已完成，因此多个选项卡不能相互阻止，这会导致浏览体验不佳......但是为什么选择异步来解决这个问题......然后，雪上加霜，它决定将事务锁定在表上而不是实体上。
Google Bigtable 有完全相同的问题，应用引擎上的多个实例可能会在读取和写入时相互阻塞，因此该团队决定在实体级别进行锁定（技术上是实体组，但与本次讨论没有区别）。他们对数万亿个实体和同步 api 没有任何问题。
所以我的问题是，为什么 indexeddb 没有设计为同步的，并阻止具有用户指定超时的实体？我在这里想念什么？
IndexedDB API 没有提到锁定表或行，想必是由浏览器决定。它所说的事务是它的行为，例如：
允许以“只读”模式打开的任意数量的事务同时运行
实现必须确保另一个事务不会修改“读写”事务范围内的对象存储的内容。
Chrome 使用Leveldb并且没有表或对象存储的概念。[为清楚起见编辑]
Appengine 是后端系统，而 javascript 是前端。任何 JS 进程都应该在 200 毫秒内完成，这样 UI 就不会显得生涩。任何有意义的数据库请求，因为它会涉及 IO，所以很容易花费 200 毫秒。所以即使你有同步 API，它在 UI 线程中也没有用。
目前异步 IndexedDB API 的设计使得很难编写会冻结 UI 线程的糟糕 JS 代码。这是一个很好的 API 设计。
在 appengine 中，严肃的应用程序使用异步 API。使用同步 API 而不是浪费 CPU 时间没有任何好处。同步 API 并不比异步 API 快。实际上，同步 API 是对异步 API 的包装。IndexedDB API 实现也是如此。