On Tue, Feb 21, 2012 at 1:40 PM, Joshua Bell <jsb...@chromium.org> wrote:
> In a page utilizing Indexed DB, what should the expected behavior be for
> an IDBTransaction created during the window.onunload event callback?
>
> e.g.
>
> window.onunload = function () {
> var transaction = db.transaction('my-store', IDBTransaction.READ_WRITE);
> transaction.onabort = function () { console.error('aborted'); };
> transaction.oncomplete = function () { console.log('completed'); };
>
> var request = transaction.objectStore('my-store').put('value', 'key');
> request.onsuccess = function () { console.log('success'); };
> request.onerror = function () { console.error('error'); };
> };
>
> I'm not sure if there's a spec issue here, or if I'm missing some key
> information (from other specs?).
>
> As the execution context is being destroyed, the database connection would
> be closed. (3.1.1). But the implicit close of the database connection would
> be expected to wait on the pending transaction (4.9, step 2). As written,
> step 6 of "lifetime of a transaction" (3.1.7) would kick in, and the
> implementation would attempt to commit the transaction after the unload
> event processing was completed. If this commit is occurring asynchronously
> in a separate thread/process, it would require that the page unload
> sequence block until the commit is complete, which seems very undesirable.
>
> Alternately, the closing page could abort any outstanding transactions.
> However, this leads to a race condition where the asynchronous commit could
> succeed in writing to disk before the abort is delivered.
>
> Either way, I believe that that after the unload event there are no more
> spins of the JS event loop, so therefore none of the events
> (abort/complete/success/error) will ever be seen by the script.
>
> Is there an actual spec issue here, or is my understanding just incomplete?
>
>
... and since I never actually wrote it: if there is a spec issue here, my
suggestion is that we should specify that any pending transactions are
automatically aborted after the unload event processing is complete. In the
case of transactions created during unload, they should never be given the
chance to start to commit, avoiding a possible race condition. (Script
would never see the abort event, of course.)
