[w3c/IndexedDB] treat writes to the DB that have no success handler as having called commit (Issue #482)

fergald created an issue (w3c/IndexedDB#482)

If a transaction becomes inactive and no request for that transaction has a `success` event handler then there can be no further writes. We can act as if `commit` had been called on that transaction and shortcut the process.

Consider the following code

```js
function putSomething(db) {
  const kStore = "store";
  const transaction = db.transaction([kStore], 'readwrite');
  const store = transaction.objectStore(kStore);
  store.put(...);
}
```

As written above, in Chrome, this will cause
1. An IPC from the renderer to the storage process.
2. A response back to the renderer.
3. The renderer will find that there is no `success` handler.
4. The renderer will signal to the storage process to commit, requiring one more IPC.
5. During most of this time a lock is held on the store.

If instead, we were to notice that there is no `success` handler on the request by the end of the JS task, we could silently call `commit`, remove 2-4 and shorten the duration of that lock.

This is even more of a problem when people naively do this in a `pagehide`/`unload`/`visibitilitychange` handler at end of page life. In that case, steps 2-4 do not occur as the has already been destroyed. This leaves the write uncommitted. In the case where the page is going into BFCache, it leaves the lock held while in BFCache, resulting in eviction if another document contends for that lock.

The one caveat is that currently, this is an observable change in behaviour. JS can add the `success` handler at any point after the `put`, as long as it's before step 3 above and add new writes to the transaction. I think adding success handlers later (i.e. in a different JS task) is a pretty weird thing to do, with unpredictable outcomes, it seems unlikely anyone is depending on that behaviour. It's also observable in that `put`s from `pagehide`/`unload`/`visibitilitychange` would start working.

@SteveBeckerMSFT @evanstade 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/482
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/482@github.com>