Phil, In order to disable totally journaling, I think (to be confirmed by real sqlite experts though) that you could patch each 4 calls to the function: int sqlite3BtreeFactory(const sqlite3 *db, const char *zFilename, int omitJournal, int nCache, int flags, Btree **ppBtree); using always 1 as the third parameter (omitJournal) instead of 0 in the following files: - attach.c (line 136) - build.c (line 3212) - main.c (line 1025) (- and in vdbe.c (line 2611) but omitJournal argument already equals 1 in this file)
Keep us informed if this works. Aladdin > From: [EMAIL PROTECTED] > To: sqlite-users@sqlite.org > Date: Fri, 11 Apr 2008 17:45:35 -0500 > Subject: Re: [sqlite] Any way to disable journaling & rollback? > > Holding commits with a timeout is a feasible solution. However, in my > application it is somewhat complex to implement. Multiple threads are > accessing the database, and read requests usually run in a different thread > than writes. I don't want reads to be blocked while a commit timeout waits, > so a read would have to force a commit. I don't think one thread can commit > transactions for another thread, so I would have to set up an inter-thread > queueing system to allow readers to notify writers in different threads that > commits need to be done. Since commits are done in multiple places, this > approach will get messy fast. > > I think removing the FlushFileBuffers call (which is normally done on every > commit) is the best solution. It is not as fast as totally turning off > journaling, but it allows my program to run 20 times faster without the > complexity of trying to hold commitments. Also, journaling _is_ being done > (just not forced to the disk). So if my application crashes but Windows > continues to run, the journaling will eventually get flushed from Windows > cache to disk, and it should be available for a rollback. > > If I can figure out how to totally turn off journaling, I will do some > timing tests to see how much that speeds things up. It certainly won't be a > factor of 20, but a factor of 2 is possible. > > A new pragma "journaling=[off|on]" would be nice. > > Key wrote: > > Removing the journalling will certainly cause you lots of grief in the event > of a "crash"... > > You could do the following, > The write code (inserts) will queue incoming data into an > "array/storage in memory etc..." > When the first row is captured set a timer. > When either the timer expires or you reach a row limit threshold, > write the data to sqlite in a batched transaction. > > This way you get good performance and reliablity! But if you code crashes > and > you don't keep persistent what was in memory you'll loose that data. > You'll probably need to do some tuning of the timer/row limits to get a > balance between performance > and potential data loss. > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _________________________________________________________________ Avec Hotmail, vos e-mails vous suivent partout ! Mettez Hotmail sur votre mobile ! http://www.messengersurvotremobile.com/?d=hotmail _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users