On Tue, Mar 01, 2011 at 12:20:32PM -0800, mmudi scratched on the wall: > > We are using sqlite version 3.3.17 in a production environment, and are > facing an issue where a particular process is not releasing the read lock on > the sql file. This locks up the database when any write operations are > attempted by other processes. The process under question is not multi > threaded and stack trace reveals that the process is not stuck in an SQLite > library call but is processing other requests. > > A code review of the DB access API has not revealed any resources or calls > that have not been closed/freed properly.
This can be verified by attempting to close the database connection. If there are still unresolved statements, an error will be returned. Additionally, you must actually call _reset() or _finalized() on a statement, even if it is run until _step() returns SQLITE_DONE. In some cases, in some versions of SQLite, the locks are not released until the statement is actually reset/finalized. > Questions > -- > From my debugging efforts, the issue appears to be that the process entered > the sqlite library at some point in its operation, acquired a read lock, and > returned from the library, but failed to release the read lock. Under what > circumstances can this occur? Many. But if you're correctly resetting all your statements, the most likely cause is an SQL "BEGIN" was issued without a corresponding "COMMIT" or "ROLLBACK." -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
