Remove dummy connection/statement from the History database

VERIFIED FIXED in Firefox 3 alpha6

Status

()

P2
normal
VERIFIED FIXED
12 years ago
9 years ago

People

(Reporter: brettw, Assigned: dietrich)

Tracking

Trunk
Firefox 3 alpha6
Points:
---
Dependency tree / graph
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
I have discovered that sqlite now keeps the cache between transaction automatically, removing the need for this extra connection stuff that I added. I think you need to sync to a new sqlite for this to work.

It should be possible to delete the mDummyDBConn, mDBDummyStatement, StartDummyStatement(), StopDummyStatement().

According to Dr. Hipp, we should also use "PRAGMA locking_mode=EXCLUSIVE;". This will keep the file locked all the time. It will increase performance by truncating the journal instead of re-creating the file which should be faster. It will also be dramatically faster if some virus scanners are installed (apparently, they slow down creates much more than writes).

If we do this, we should add locking to the I/O layer for extra safety (bug 329960). This will prevent stupid people from opening the DB manually while we are using it and corrupting it. That bug was stalled because the old way of having multiple connections made locking complex. Now you should just be able to lock when it says.
thanks for the bug report, brett.  do you know which version of sqlite we need for this (http://www.sqlite.org/changes.html), or do you recommend we move to the latest-and-greatest?
(Reporter)

Comment 2

12 years ago
I don't know of any reason not to move to the latest.
(Assignee)

Updated

12 years ago
Blocks: 329960
(Assignee)

Updated

12 years ago
Flags: blocking-firefox3?
Priority: -- → P2
Flags: blocking-firefox3? → blocking-firefox3+

Updated

12 years ago
Target Milestone: --- → Firefox 3 alpha6
(Assignee)

Updated

12 years ago
Depends on: 341137
(Assignee)

Updated

11 years ago
Assignee: nobody → dietrich
(Assignee)

Updated

11 years ago
Blocks: 327350
(Assignee)

Comment 3

11 years ago
Created attachment 269303 [details] [diff] [review]
fix v1

removes the dummy connection code, adds the locking pragma. more info about the lock here:

http://www.sqlite.org/pragma.html#pragma_locking_mode
Attachment #269303 - Flags: review?(sspitzer)
Comment on attachment 269303 [details] [diff] [review]
fix v1

r=sspitzer
Attachment #269303 - Flags: review?(sspitzer) → review+
(Assignee)

Comment 5

11 years ago
Checking in toolkit/components/places/src/nsNavHistory.cpp;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.cpp,v  <--  nsNavHistory.cpp
new revision: 1.135; previous revision: 1.134
done
Checking in toolkit/components/places/src/nsNavHistory.h;
/cvsroot/mozilla/toolkit/components/places/src/nsNavHistory.h,v  <--  nsNavHistory.h
new revision: 1.83; previous revision: 1.82
done
(Assignee)

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Status: RESOLVED → VERIFIED
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.