IndexedDB: Cancel transaction inactivity timer on Commit() arrival

IndexedDB: Cancel transaction inactivity timer on Commit() arrival

After processing a batch of requests, our IDB transaction initiates an
inactivity timer; if the timer fires before any further requests
arrive from the front-end we assume the front-end is wedged and abort
the transaction. The timer is be stopped on any new request, including
a signal to commit or abort. During the introduction of blobs, the
"stop timer on commit signal" ended towards the end of the commit
flow, but it should be towards the start so it doesn't fire if the
back-end is busy.

Speculative fix for frequent timeouts of W3C web-platform-tests seen
on slow bots.

R=cmumford@chromium.org

Committed: https://crrev.com/d71e9bcb98c8097b6192f45af7ac663a2ccc255d
Cr-Commit-Position: refs/heads/master@{#292035}

[jsbell, 2014-08-22 23:38:41]

This shouldn't be necessary, and almost certainly doesn't account for the aborts
seen in the tests, but it *is* more correct to stop the timer on the first sign
of front-end activity.

cmumford@ - WDYT?

[cmumford, 2014-08-26 21:43:13]

On 2014/08/22 23:38:41, jsbell wrote:
> This shouldn't be necessary, and almost certainly doesn't account for the
aborts
> seen in the tests, but it *is* more correct to stop the timer on the first
sign
> of front-end activity.
> 
> cmumford@ - WDYT?

The change lgtm.

Personally I'm not in favor of having this timer and think we should consider
doing away with it. I just don't like the thought of a slow system causing
transaction inactivity and thus causing the transactions to abort.

[jsbell, 2014-08-26 21:49:09]

> Personally I'm not in favor of having this timer and think we should consider
> doing away with it. I just don't like the thought of a slow system causing
> transaction inactivity and thus causing the transactions to abort.

Agreed, with appropriate thought. We put it in to address real needs - based on
reports of txs stuck waiting - but we can probably come up with something better
or measure more carefully to understand what's going on.

[jsbell, 2014-08-26 21:49:30]

The CQ bit was checked by jsbell@chromium.org

[commit-bot: I haz the power, 2014-08-26 21:50:55]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jsbell@chromium.org/502643003/1

[commit-bot: I haz the power, 2014-08-26 23:43:39]

Committed patchset #1 (1) as 8a5482b2b81fc4d6ef1db36a651bcfd43c58ac96

[jsbell, 2014-08-29 22:37:23]

Huh... this appears to have improved this markedly on the bots. Didn't expect it
to.

The failure clusters (due to aborts) stop as soon as this lands:

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRu...

[commit-bot: I haz the power, 2014-09-10 02:47:30]

Patchset 1 (id:??) landed as
https://crrev.com/d71e9bcb98c8097b6192f45af7ac663a2ccc255d
Cr-Commit-Position: refs/heads/master@{#292035}