I'm not sure we should include this in the IDB spec. The reason is that I would expect every browser to provide different guarantees based on their internals. In our case after the Javascript engine finishes its processing, the server starts its processing and once started the server started its transaction it would be difficult for us to abort the transaction. However, if the page is navigated while the Javascript engine is still processing, the transaction will never be committed.
You can also get into all kinds of corner cases where the Javascript engine finished processing but the server requests haven't started, or the Javascript engine finished processing and the server request was sent. Adding this to the spec would make it difficult for us to provide unique solutions to are spec compliant. Israel On Tuesday, February 21, 2012 2:34 PM, Joshua Bell wrote: On Tue, Feb 21, 2012 at 1:40 PM, Joshua Bell <jsb...@chromium.org<mailto: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.)
