On Tue, May 11, 2010 at 12:12:09PM -0700, Jim Terman scratched on the wall: > We have sqlite databases in a memory shared cache environment where > individual tables may be locked out by other processes.
If other processes are doing the locking, the whole database is locked. > This means that we have to worry about SQLITE-BUSY errors and make > sure are code can handle this. You have to do this regardless, but yes. > There is some internal debate about whether we have to worry about table > locks only at the beginning of a transaction, or whether a commit itself > can generate them. Either. If you open the transaction with just BEGIN, the commit itself can generate an SQLITE_BUSY and fail. If you open with a BEGIN EXCLUSIVE, the commit should not generate an SQLITE_BUSY error, but the BEGIN can. http://sqlite.org/lang_transaction.html > The question is, if we have a transaction with several sql statements > that execute without any locks, is there anyway that the commit itself > would encounter a lock. You can't execute a statement without *any* locks. > We know that the commit involves writing of the > results from memory to disk, but would any potentials locks actually be > deferred until this point? Yes. Some locks. Some times. Depending on the transaction, the commands, and the size of the update. But the core of your question is that you need to make all your transactions exclusive =OR= you need to deal with COMMIT returning an SQLITE_BUSY *and* possibly rolling back your transaction. Actually, it is recommend you always rollback any transaction after receiving an SQLITE_BUSY to avoid some types of deadlock situations. http://sqlite.org/lockingv3.html http://sqlite.org/c3ref/busy_handler.html -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users