[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
Wed Jul 1 08:57:29 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=25711
------- Comment #33 from benm at google.com 2009-07-01 08:57 PDT -------
(In reply to comment #31)
> Hmmmm... I liked how the collection was a private detail of DatabaseThread. The
> "don't forget to close what you opened" behavior was well encapsulated in that
> class, no other agency was involved. Its been gradually moving away from that
> with greater fine grained dependencies of other database classes just a ptr
> deref away from each other, first more into the Database class, and now into
> the DatabaseTracker class.
>
> The reason I mention this is that we have plans to "split" the DatabaseTracker
> class for use in chrome's multi-process, sandboxed world. This function
> (maintaining a collection of what database is opened on what thread and then
> acting on that at thread end) would be one more hair to split along those
> lines.
>
> Removing the test after execution of each DatabaseTask was an improvement. The
> only real issue with that improvement was the Mutex usage (a smaller issue was
> copying the collection on exit). I think open/close is always be called on the
> database thread directly. If thats true, please consider simply removing the
> Mutex.
>
OK, if leaving it in the DatabaseThread makes the coming restructuring for
Chrome easier, I'm fine with that. I'm not sure there's a better way to iterate
the set other than taking a copy as we call close on each value in the set,
which then removes it from the set and hence modifies what we're iterating
over. I guess we could instead construct a vector of databases to close and
then loop over it to actually call close... does rather seem like six of one
and half a dozen of the other though :). I've removed the mutex and replaced it
with a couple of asserts.
Cheers, Ben
--
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