- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Mar 2012 03:02:49 +0100
- 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