449987 - open cookie db unshared and exclusive

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[[e-mail]]

sdwilsh says this will help with perf a little, and it should work just fine since we don't expect other people to mess with our db while we're running and have it open.

Comment 1

[Eric Butler [:ebutler]]

Attachment: ver 1

flagging dwitte for review

Comment 2

[Eric Butler [:ebutler]]

Attachment: ver 2

added a comment to explain what the pragma is doing.

Comment 3

[[e-mail]]

Comment on attachment 333261 [details] [diff] [review]
ver 2

r=dwitte, i assume this passes unit tests?

Comment 4

[Eric Butler [:ebutler]]

Yes, it still passes unit tests. Flagging checkin-needed.

Comment 5

[[e-mail]]

thanks! maybe bholley can help out with checkin ;)

Comment 6

[Bobby Holley (:bholley)]

pushed in 42a7ea1650c9

Comment 7

[jm]

Until now concurrent access by reading and even writing the file by third party applications was possible and supported, even if Firefox was running. This is now hindered by the lock.
Is there any evidence of measurable performance improvement or shouldn't it be reverted for copatibility reasons?
And why a read lock as well?

Comment 8

[Shawn Wilsher :sdwilsh]

An exclusive lock is a write lock, and SQLite doesn't permit reads when a write lock is held.  This landed before beta 2 of Firefox 3.5 which was the cutoff for third-party breaking changes.

Comment 9

[jm]

So that means I missed the chance as I did not report about possible problems with that change before beta 2?

How would you recommend thrid party cookie managers to allow management of Firefox Cookies while Firefox is running? Are Firefox Plugins provided with an API to manage cookies? That plugin could then communicate with the application itself.

Comment 10

[[e-mail]]

Firefox extensions have access to APIs to do anything they want with cookies.

Comment 11

[jm]

However, how can external windows applications communicate with Firefox extensions and raise Javascript functions in the externsion's code? Is there support for mutexes, WM_COPYDATA messages, names pipes or similar? How can extensions respond to these messages sending data back to the application?

As stated, it seems this will be the only workaround to allow cookie management from an external application while firefox is running, because of the exclusive locking mode that is now used for the cookie database.

Comment 12

[jm]

Named pipes is no solution currently, see Bug 500151.

Comment 13

[jm]

This behavior seems to have been changed in FF4, b7, it sqlite-wal and -shm files (write ahead locking).

Comment 14

[Shawn Wilsher :sdwilsh]

(In reply to comment #11)
> However, how can external windows applications communicate with Firefox
> extensions and raise Javascript functions in the externsion's code? Is there
> support for mutexes, WM_COPYDATA messages, names pipes or similar? How can
> extensions respond to these messages sending data back to the application?
External applications shouldn't be modifying the database anyway; it won't change things until Firefox is restarted, and they run the risk of corrupting the database.

> As stated, it seems this will be the only workaround to allow cookie management
> from an external application while firefox is running, because of the exclusive
> locking mode that is now used for the cookie database.
As stated above, this wasn't doing what you wanted anyway, and it won't even in Firefox 4 (and any bug asking it to work would be resolved as WONTFIX)