Beginning everything with BEGIN IMMEDIATE should eliminate the possibility of deadlock, but you will serialize read-only operations. If your transactions are short or contention is low, using BEGIN IMMEDIATE makes things easy.
However, if you find that you have a set of read-only operations that run frequently, or take a long time, you may want to consider simply using BEGIN on these (or for single statement reads, you could leave the transaction wrapping out altogether). Pat -----Original Message----- From: Jiri Hajek [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 11:33 AM To: sqlite-users@sqlite.org Subject: RE: [sqlite] Problems with multiple threads? > If it is inconvenient to rollback and retry the entire transaction, then start the transaction initially with BEGIN EXCLUSIVE. > This will acquire the reserved lock immediately (instead of waiting to the first write occurs) and so you will either get an > SQLITE_BUSY right away (when it is a simple matter to just rerun the BEGIN EXCLUSIVE statement until it works) or you can be > assured of never getting another SQLITE_BUSY again until you try to COMMIT (and there too, you can simply rerun COMMIT > repeatedly until it works.) Thanks, I overlooked that by default transactions are DEFERRED in SQLite. It really fixes the problem. As I think about it, if I make _all_ transactions in my application IMMEDIATE, there shouldn't be any risk of a deadlock, right? Thanks, Jiri
