I have been reading about WAL, and there are a few questions I would like to ask.
1) I am slightly confused about readers building the WAL index. It says way down the page quote: Using an ordinary disk file to provide shared memory has the disadvantage that it might actually do unnecessary disk I/O by writing the shared memory to disk. However, the developers do not think this is a major concern since the wal-index rarely exceeds 32 KiB in size and is never synced. Furthermore, the wal-index backing file is deleted when the last database connection disconnects, which often prevents any real disk I/O from ever happening. /quote In a situation where I have a web application (php based) in essence each request makes a database connection, does a couple of queries, and exits (thereby closing the connection). Unless my site gets really loaded (which in the application I am thinking of porting over to SQLite doesn't happen) it is quite frequent that there are no open database connections. Does this mean that every web access has to rebuild the index just to perform a query? is this a long process? 2) If the WAL is not synced back to the database (because the 1000 pages have yet to be created), is it still in non volatile storage, synced at the end of the last commit. In other words, if the server happens to get shut down and rebooted, will the WAL still be there and continue to function from the last committed transaction. (And, given question 1 the WAL index will just be rebuilt). 3) When the 1000 page (or perhaps a smaller number that might be more appropriate in my case) watermark is passed, does the writer (if not interrupted) completely clear the WAL. 4) Is the escalation of locks process process still in place. In particular, are the semantics of BEGIN, BEGIN IMMEDIATE and BEGIN EXCLUSIVE the same? (My current approach is that for web access that does only reads, I do a BEGIN, and then the SELECTS and then COMMIT, for one that has some INSERT and UPDATES, I do a BEGIN IMMEDIATE, do an application level check (via SELECT) on a version field on the database to ensure its the same as when I originally read it, ROLLBACK if it isn't, but if it is proceed with the INSERTS and UPDATES and finally COMMIT). -- Alan Chandler http://www.chandlerfamily.org.uk _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
