On Thu, Jun 21, 2012 at 09:53:57AM +0100, Pontus Bergsten scratched on the wall:

> It seems that it is very important that every statement evaluation is
> concluded with a sqlite3_reset() (or sqlite3_finalize() if the statement
> is not going to be used anymore). 

  That's true, and as others have pointed out, it is fairly well

> "You should be in the habit of calling sqlite3_reset() on each query as
> soon as that query finishes. Otherwise the query *might* leave a
> read-lock on the database file and thus prevent subsequent write
> operations for working correctly."
> I suppose that the "*might* locking part" should be explicitly stated
> in the SQLite API documentation for step/reset.

  I believe the documentation is purposely vague about locking.

  The documentation is clear that you should call _reset() or
  _finalize() reasonably soon after you're done with a statement

  As for the locking issue, I had a private conversation with R. Hipp
  about this when working on "Using SQLite"... are locks released
  when _step() returns SQLITE_DONE, or are they released when
  _reset()/_finalize() is called?  He said it varied, both statement
  to statement, as well as version to version.  The documentation made
  it clear which APIs a well-behaved program had to use; the rest was
  just internals (as most of locking is).  How things were handled
  changed from time to time to get better performance, reduce
  deadlocks, etc.

  Mind you, this was several years ago, back in the late 2.6 days.  It
  was before WAL.  I have no idea if locking is now more consistent (or
  less).  I'm sure WAL mixed things up quite a bit.
  Regardless, I think the general principal still stands... Locking is
  generally considered an internal function of SQLite that the vast
  majority of programmers never directly deals with.  We have to deal
  with some of the ramifications, but not the process itself.  Allowing
  the SQLite devs to alter the locking scheme depending on journal modes,
  platforms, code-refactoring, or whatever, allows the SQLite dev team
  the freedom to change internal details, and things will work just
  fine-- as long as an application follows the well documented API
  In short, you should never be deciding to call or not call _reset()
  or _finalize() because of locking semantics.  If your program can call
  one of those APIs and maintain correct flow, it should be calling them.


Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Intelligence is like underwear: it is important that you have it,
 but showing it to the wrong people has the tendency to make them
 feel uncomfortable." -- Angela Johnson
sqlite-users mailing list

Reply via email to