Re: [IndexedDB] Transactions during window.unload?

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