W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [IndexedDB] Transactions during window.unload?

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 1 Mar 2012 03:02:49 +0100
Message-ID: <CA+c2ei8moac41h=W=74o6DisbUDus8D8zL7MzcmgE5RU-CS+mg@mail.gmail.com>
To: Joshua Bell <jsbell@chromium.org>
Cc: public-webapps@w3.org
The whole issue of "what happens if the user leaves the page while
there are running transactions" is something that we've left up to
implementations. IIRC this was debated a long time ago but the
conclusion was basically that implementations will use different
strategies for dealing with this. Basically make it a
quality-of-implementation issue.

It's a somewhat different scenario when the transaction isn't even
started until in onunload since we'll sort of know that that's a racy
situation. Technically we could forbid any transactions from being
started after unload has started to fire.

Ultimately I don't have a strong opinion. It seems like there are very
good use cases for wanting to store data in onunload, but it seems
very hard to get it to work.

/ Jonas

On Tue, Feb 21, 2012 at 10:40 PM, Joshua Bell <jsbell@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?
Received on Thursday, 1 March 2012 02:03:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC