IndexedDB请求和事务的时间安排

Question

我正在读IndexedDB (在developers.google.com和MDN上)。据我所知，通常做任何事情的模式是

1. 创建请求对象，
2. 添加onsuccess、onerror和可能更多的回调
3. 没有3号。

然后请求最终完成它的任务，并调用我的一个函数(或者，如果使用包装器，则确定一个承诺)。我错过了某种承诺的步骤。假设请求的实现是异步的，这是否意味着它可以发生在不同的线程上？如果是这样的话，如果非常快(或者我的代码非常慢)并且在我设置回调之前设法在1到2之间终止了怎么办？

还是请求在空闲期间运行在同一个线程上？如果是这样的话，我可以想象会发生这样的情况:我压倒了请求队列(比如在一个非常低调的设备上)。如果回调不是一个选项(我的函数仍在运行)，那么这将是什么信号呢？

Answer 1

写入请求(如put或add )会将要完成的工作附加到创建它的事务中。写请求在事务提交时提交。在检测到没有更多的请求要处理后不久，事务就会提交。

提交意味着什么要复杂一些，因为我认为Firefox和Chrome有不同的含义，或者在过去的某个时候，Chrome在内存中提交，后来刷新到磁盘，但是Firefox直到刷新到磁盘，或者向后提交，对不起。不过，冲入磁盘可能是迂腐的/仲裁的，所以我不担心这个区别。尤其是当你对事物不熟悉的时候。

若要检测事务何时提交，请侦听事务的完整事件。

若要检测事务何时因错误而回滚而不提交，请侦听事务的错误事件。这里还有一个奇怪的注释，事务不具有error属性，只有请求才具有。因此，事务级别上的错误事件将对应于来自其请求之一的错误。

若要检测事务何时成功或未完成，请同时侦听完整事件和错误事件。

JavaScript是单线程的。indexedDB为您管理线程等。您不需要担心线程。

如果您的慢代码在请求期间终止，事务将无法成功完成。数据库将处于与启动请求之前相同的状态，就好像请求从未发生过一样。

如果您真正慢的代码在第一个请求完成后但在随后的请求在同一事务中完成之前终止，则事务将无法成功完成。只有当所有请求都成功完成时，事务才能成功完成。因此，数据库将处于启动第一个请求之前的相同状态，就好像事务中没有发生任何请求一样。

如果indexedDB由于某种性能压力错误而无法完成事务，那么所讨论的事务本质上不会提交，并且不会发生持久的状态更改。这将引发某种更一般的JavaScript错误，或者性能允许，只是一个正常的事务错误。