On Fri, Jun 16, 2006 at 12:35:33PM -0400, [EMAIL PROTECTED] wrote: > > Out of curiosity why won't flock() work? > > Process A wants to modify the database, so it flock()s > the rows it needs to changes and starts changing them. > But half way in the middle of the change, somebody sends > process A a SIGKILL and it dies. The OS automatically > releases the flocks as process A dies, leaving the > database half-way updated and in an inconsistent state, > with no locks. > > Process B comes along and opens the database, see the > inconsistent state, and reports database corruption.
Would it, at least in principle, be feasible to have Process B then take a lock (hm, which lock?), notice somehow that A's transaction failed without either committing or rolling back, read the rollback journal written earlier by Process A, and rollback A's half-done work? What in practice makes that not a good idea? Would using a non-overwriting MVCC storage layer a la PostgreSQL (but still using client SQLite processes only, no client/server arrangement) make any of the above easier or better? Note, I'm not suggesting that you should implement anything like this in SQLite, I'm just curious in general... -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
