On Aug 9, 2010, at 11:17 AM, David Barrett wrote: > 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".
I think it will be SQLITE_BUSY in all cases, not SQLITE_LOCKED. In general, you only get SQLITE_LOCKED if you are blocked because of something in the same process (e.g. other shared cache clients). You get SQLITE_BUSY if blocked by some other process. Or if you are blocked by some other non-shared-cache connection in the same process. The answer to (3) would be "No." with a WAL mode database. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
