> 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.

My concept of always consistent is a.. for lack of a better term... virtual 
concept.  That is, anytime anything accesses the database, as a database, that 
database is always consistent.

This means that before any application can be permitted to access (e.g. open) 
the database, that database should be made consistent.  Then, and only then, 
should the application be able to open it.  In another words, when I go to open 
a database, if the engine cannot provide me a consistent database for my 
connection, I should be informed of that.  Not later when I try to do something.

> >
> > 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.

Why can't Process X roll it back?  Isn't a read-only designation is to prevent 
insert and updates and such on the database.  If I open a database as 
read-only, does that mean I can't create a temporary table?  Does it mean that 
I can't perform a complex order by that requires the engine to create temporary 
tables?

The only reason I can think of is that Process X has no way of knowing that 
it's a hot journal vs. a journal being used by a process that's just taking a 
long time.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to