为什么IndexedDB被设计为具有锁定表的异步API？

Question

为什么IndexedDB被设计为具有锁定表的异步API？

我的理解是异步部分已经完成，因此多个选项卡不能互相阻塞，这会导致糟糕的浏览体验......但为什么选择异步来解决这个问题...然后，添加侮辱伤害，决定锁定交易而不是实体。

Google Bigtable与app-engine上的多个实例存在完全相同的问题，可能会在读取和写入时相互阻塞，因此团队决定在实体级别进行锁定（技术上是实体组，但对此没有区别）讨论）。万亿实体和同步api没有问题。

所以我的问题是为什么indexeddb没有被设计为同步，并且阻塞了具有用户指定超时的实体？我在这里缺少什么？

Answer 1

IndexedDB API没有提到锁定表或行，假设它由浏览器来决定。关于交易的说法是它的行为，例如：

  

允许以“只读”模式打开的任意数量的交易   同时运行

     

实施必须确保另一个交易没有   修改“readwrite”事务中对象存储的内容   范围。

Chrome使用Leveldb并且没有表格或对象存储的概念。 [编辑清晰]

Appengine是后端系统，而javascript是前端。任何JS进程都应该在200毫秒内完成，因此UI看起来不会生涩。任何有意义的数据库请求，因为它将涉及IO，可能很容易需要200ms。因此，即使您有同步API，它在UI线程中也没用。

目前异步IndexedDB API的设计使得编写一个会冻结UI线程的糟糕JS代码非常困难。这是一个很好的API设计。

在appengine中，认真的应用程序使用异步API。使用同步API没有任何好处，而不是浪费CPU时间。 Sync API并不比异步API快。事实上，同步API包装在异步API上。 IndexedDB API implementation也是如此。