IndexedDBがテーブルをロックする非同期APIとして設計されたのはなぜですか？
私の理解では、非同期部分は複数のタブが互いにブロックできないように行われているため、ブラウジングエクスペリエンスが低下します...しかし、なぜこの問題を解決するために非同期が選択されたのですか...そして、怪我に侮辱を加えるために、エンティティではなくテーブルでトランザクションをロックすることが決定されました。
Google Bigtableには、app-engineの複数のインスタンスが読み取りと書き込みで相互にブロックする可能性があるというまったく同じ問題があります。そのため、チームはエンティティレベル（技術的にはエンティティグループですが、この説明に違いはありません）でロックを行うことにしました。何兆ものエンティティと同期APIに問題はありません。
だから私の質問は、indexeddbが同期して、ユーザー指定のタイムアウトでエンティティをブロックするように設計されていないのはなぜですか？ここで何が欠けていますか？
IndexedDB APIは、テーブルまたは行のロックについては言及していません。おそらく、決定するのはブラウザ次第です。トランザクションについてそれが言ったことは、その振る舞いです、例えば：
「読み取り専用」モードで開かれた任意の数のトランザクションを同時に実行できます
実装では、別のトランザクションが「読み取り/書き込み」トランザクションのスコープ内のオブジェクトストアの内容を変更しないようにする必要があります。
ChromeはLeveldbを使用しており、テーブルやオブジェクトストアの概念はありません。[わかりやすくするために編集]
Appengineはバックエンドシステムですが、javascriptはフロントエンドです。UIがぎくしゃくしたように見えないように、JSプロセスは200ミリ秒で終了する必要があります。意味のあるデータベース要求はIOを伴うため、簡単に200ミリ秒かかる可能性があります。したがって、同期APIを使用している場合でも、UIスレッドでは役に立ちません。
現在、非同期IndexedDB APIは、UIスレッドをフリーズさせる不正なJSコードを記述することが非常に困難になるように設計されています。これは優れたAPI設計です。
appengineでは、本格的なアプリは非同期APIを使用します。CPU時間を無駄にするのではなく、同期APIを使用する利点はありません。同期APIは非同期APIより高速ではありません。実際、同期APIは非同期APIをラップしています。これは、 IndexedDBAPIの実装にも当てはまります。