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

Reply via email to