329960 - Keep DB file locked while AsycIO is working

Status: RESOLVED INVALID

(Toolkit :: Storage, defect, P4)

Description

[Brett Wilson]

I am worried about other programs coming through and trying to share the file, which will break with our asynchronous I/O. The locks aren't perfect, but should give a measure of safety.

Comment 1

[Mike Schroepfer]

Vlad - do we need this for 1.8.1?  What are the sharing cases we are worried about ?

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

The issue is that if some other process tries to write to the database while we have async IO going, it could get corrupted.  I don't think this is a security issue; it can only lead to file corruption, and even then it would be rare (they'd have to explicitly run something that tries to modify the storage db).  Unless there's something that Brett saw that I'm not seeing, I don't think this should block b1.

Comment 3

[Brett Wilson]

I don't think it should block B1 or even Fx2. We already lock the profile for other reasons, and there are other files that will get corrupted as well if there is >1 writer.

Comment 4

[Mike Connor [:mconnor]]

minusing based on brett and vlad's comments.

Comment 5

[Brett Wilson]

I'm not sure if/when we're going to do this.

Comment 6

[Brett Wilson]

This should be easy once bug 380345 is submitted. Just locking the file when requested should be sufficient. Currently, I think we need to track how many connections there are to know when to lock and unlock, which is difficult and why it's been stalled for so long.

Comment 7

[Shawn Wilsher :sdwilsh]

This is the changes that the sqlite people made with their async stuff to enable file locking:
http://www.sqlite.org/cvstrac/filediff?f=sqlite/src/test_async.c&v1=1.10&v2=1.11

Comment 8

[Shawn Wilsher :sdwilsh]

No longer needed since we no longer do async IO.