I *think* I know the answers these questions, but can you please confirm them for me?
1) Does the sqlite3 command-line app .backup command use the http://www.sqlite.org/backup.html API, and thus only read-lock the database for brief moments (rather than read-locking the database for the entire span of the backup)? I think the answer is "yes". 2) When an application performs read-only selects on the database in parallel to the .backup command being run on the database, will the application occasionally get the SQLITE_LOCKED return value to the sqlite3_exec() command? I think the answer is "no". 3) When an application performs read/write queries on the database in parallel to the .backup command being run on the database, will the application occasionally get the SQLITE_LOCKED return value to the sqlite3_exec() command? I think the answer is "yes". 4) Is there any built-in way to identify what other process has locked the database when you get the SQLITE_LOCKED return value? I think the answer is "no" 5) Are any of the above answers affected in any way by the new write-ahead logging (WAL) feature? I think the answer is "no". 6) Is there anything an application can do to somehow coordinate with or otherwise signal to the .backup script so as to avoid or minimize locking conflicts? I think the answer is "no". Basically, I'm trying to figure out the best way to do live backups of a database thats in active read/write use. Right now I'm just doing a copy of the live file and then running .dump on the copy, but that's obviously not ideal and occasionally has corruption issues (especially as load increases). I'm considering using .dump, but I'd like to make sure the application is prepared to handle SQLITE_LOCKED correctly. Currently it just does a retry after a random timeout, but this obviously isn't ideal. What's the best way to handle this case? Thanks! -david _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
