Bug 80193 - PageCache shouldn't know about SQLDatabase
Summary: PageCache shouldn't know about SQLDatabase
Status: RESOLVED LATER
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adam Barth
URL:
Keywords:
Depends on:
Blocks: 79327
  Show dependency treegraph
 
Reported: 2012-03-02 14:03 PST by Adam Barth
Modified: 2012-03-05 14:31 PST (History)
4 users (show)

See Also:


Attachments
work-in-progress (3.43 KB, patch)
2012-03-02 14:03 PST, Adam Barth
no flags Details | Formatted Diff | Diff
checkpoint (9.40 KB, patch)
2012-03-05 14:12 PST, Adam Barth
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2012-03-02 14:03:18 PST
PageCache shouldn't know about SQLDatabase
Comment 1 Adam Barth 2012-03-02 14:03:36 PST
Created attachment 129955 [details]
work-in-progress
Comment 2 Adam Barth 2012-03-02 14:05:26 PST
This patch is subtle because currently creating *any* Database will lock out PageCache forever.  The way this works for normal ActiveDOMObjects is that PageCache is locked out only while the object is still around.

I need to study the interaction with the DatabaseThread more carefully to see which of these behaviors we want.
Comment 3 Adam Barth 2012-03-05 14:12:16 PST
Created attachment 130203 [details]
checkpoint
Comment 4 Adam Barth 2012-03-05 14:15:08 PST
So, it turns out that this approach doesn't work because AbstractDatabase can be destructed on either the JavaScript thread or the Database thread.  That means we can't inherit from ActiveDOMObject because the ActiveDOMObject destructor might call ScriptExecutionContext::willDestroyActiveDOMObject on the Database thread rather than the JavaScript thread.

We probably could solve these problems, if necessary, but the work involved doesn't seem worth the benefit at the moment.
Comment 5 Michael Nordman 2012-03-05 14:31:48 PST
> We probably could solve these problems, if necessary, but the work involved doesn't seem worth the benefit at the moment.

Yup, this comment sums up what has been a recurring theme with regard to re-factoring Database stuff to  not depend of complex objects that straddle threads (Database and SQLTransaction). Over the years there have be a few occasions where the (large) work involved may have been worth it, but at each crossroad solutions were devised that did not require it. I think the point at which we came closest to biting that bullet was when adding support for Database in workers.