"Allan, Mark" <[EMAIL PROTECTED]> wrote: > > our flash file system is 100% power-fail proof and thus the > journalling of the database for us is not required. >
Without journalling, you cannot have a ROLLBACK command. And the semantics of UPDATE become UPDATE OR FAIL instead of the default UPDATE OR ABORT. The difference is subtle, but important. Does your flash file system actually implement atomic writes of multiple changes changes distributed across a single file? Or does it just guarantee that each individual write() is atomic. I'm guessing the latter. But without the former, you can still quite easily get database corruption after a power failure if you have no rollback journal. Any single UPDATE or INSERT or DELETE command will often result in multiple write() operations to the database file. If some of those write()s complete and others do not, your database will end up in a corrupt state. Note that you do not have to take a power failure for corruption to happen. Suppose a program is writing to the database, and does 2 of the 5 writes required to make a change to the database, but then the program is kill because a different thread in the program hit a bug and segfaults, or because the program is sent a SIGKILL (or the equivalent). Without a rollback journal, the database is left in an corrupt state with no way to recover. In summary, unless you filesystem implements transactions that span multiple write() requests, you still need a rollback journal. -- D. Richard Hipp <[EMAIL PROTECTED]>
