[Webkit-unassigned] [Bug 25711] HTML5 Database becomes locked if a transaction is in progress when the page is refreshed.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu May 28 11:22:14 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=25711
michaeln at google.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michaeln at google.com
------- Comment #11 from michaeln at google.com 2009-05-28 11:22 PDT -------
> + m_sqliteDatabase.setBusyHandler(&Database::busyHandler);
...
> +int Database::busyHandler(void* context, int consecutiveInvocations)
> +{
> + UNUSED_PARAM(context);
> +
> + int milliseconds = 100;
> + while (consecutiveInvocations--)
> + milliseconds += 1.2F * milliseconds;
> + WTF::sleepMilliseconds(milliseconds);
> + return milliseconds >= MAX_SQLITE_BUSY_WAIT_TIME ? 0 : 1;
> +}
Do you actually need a custom busyHandler? The default busy handler in sqlite
has reasonable backoff logic built in (see sqliteDefaultBusyCallback). So I
wonder if you can accomplish the same thing with less code in webcore... just
database.setBusyTimeout(30seconds).
Also, about the backoff logic in your handler... I think its not going to do
what you want.
It looks like it will not return 0 until the handler sleeps at least 30 seconds
in one go. The total time prior to a sqlite function failing with a SQLITE_BUSY
error is going to be considerably longer than 30 seconds since sqlite will be
calling it repeatedly until its either no longer busy or the handler returns 0;
Also, theres extra whitespace in front of WTF::sleepMilliseconds
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list