On Fri, Feb 17, 2012 at 3:06 PM, Marc L. Allen <mlal...@outsitenetworks.com>wrote:
> > "Rolling back" means that the database is modified so that it looks > > exactly like it did before the start of the transaction. How is SQLite > > suppose to modify a read-only file? > > I suppose it's a matter of expectations. > > In my mind, a database is ALWAYS consistent. Therefore, if a hot journal > exists, the 'consistent state' is post rollback. So, I'd expect the > rollback to occur before becoming read-only. > The purpose of the hot journal is to restore the database to a consistent state following an anomalous shutdown, outside the control of SQLite, that left the database in an inconsistent state. Here is one of many possible examples to help explain why your expectations are not possible to fulfill: Suppose you have a database and you make a 2MB transaction. The database engine starts writing the transaction to disk, but after writing about 1MB, you pull the power plug. Then upon reboot, you mount the volume that contains the database as read-only. No actual hardware is able to write 2MB atomically, so it is not possible for the database file itself to be ALWAYS consistent. The rollback journal is added to restore consistency following an unclean shutdown, so that from the application's point of view, the database always appears to be consistent because the database engine automatically restores consistency when necessary. But if the inconsistency is caused by a power loss, and the volume becomes read-only during the power-loss, then the database engine never has an opportunity to restore consistency. > > If nothing else, I'd expect the Open with READONLY to fail if a hot > journal exists. > The database file might be readonly to process X and read/write to process Y. Process X opens a clean database so the open works. Process Y then crashes in the middle of a large transaction, leaving the database in an inconsistent state (with a hot journal). Process X cannot roll it back since it is read-only. But process X cannot fail its open either, since the open already succeeded. > > Marc > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
