[Webkit-unassigned] [Bug 25711] HTML5 Database becomes locked if a transaction is in progress when the page is refreshed.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25711





------- Comment #21 from michaeln at google.com  2009-06-11 12:57 PDT -------
I think you may have some race conditions?

Database::stop() can get called at any time while the db thread is working. So
in the following...

 506         if (m_database->stopped()) {
 507             LOG(StorageAPI, "Database stopped, executing
cleanupAfterTransactionErrorCallback for transaction %p\n", this);
 508             cleanupAfterTransactionErrorCallback();
 509         } else {
 510             m_nextStep =
&SQLTransaction::cleanupAfterTransactionErrorCallback;
 511             LOG(StorageAPI, "Scheduling
cleanupAfterTransactionErrorCallback for transaction %p\n", this);
 512             m_database->scheduleTransactionStep(this);
 513         }

... stopped() can return false on line 506, but by the time we get to line 512
it would return true


Maybe instead scheduleTransactionStep() could return a boolean value indicating
if the step was scheduled or not due to stop having been called. And should
interlock with the stop() method. If false is returned, the db thread would run
the cleanup code.

void Database::scheduleTransactionStep(SQLTransaction* transaction)
{
    MutexLocker locker(m_stopMutex);
    if (stopped())
      return false;
    if (m_document->databaseThread()) {
        RefPtr<DatabaseTransactionTask> task =
DatabaseTransactionTask::create(transaction);
        LOG(StorageAPI, "Scheduling DatabaseTransactionTask %p for the
transaction step\n", task.get());
        m_document->databaseThread()->scheduleTask(task.release());
    }
    return true;
}


-- 
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.