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 documented. > "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 execution. 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 sequence. 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. -j -- 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 sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
