On Fri, Feb 17, 2012 at 3:52 PM, Marc L. Allen <mlal...@outsitenetworks.com>wrote:
> > 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. > That is a good way to look at it. Or, a similar approach is to consider that the database consists of both the main database file and the hot-journal, but that the database must be transformed into just the database file without the hot journal before it can be used. > > 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. > The database might well be consistent when you open it, but then some external process outside of your control makes it inconsistent after you open it. Normally when this happens, your process will automatically recover the database before proceeding and your application will be none the wiser. But if your application lacks sufficient privileges to recover the database, then you are stuck. The above scenario can be avoided by always obtaining an exclusive lock on the database as soon as you open it. (See the PRAGMA locking_mode=EXCLUSIVE option for details.) That will prevent another process from corrupting the database out from under your unprivileged process. On the other hand, it prevents any concurrency. Which do you prefer? > > > > > > > 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 > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
