[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