On Tue, Sep 18, 2012 at 11:58 AM, Helmut Grohne <hel...@subdivi.de> wrote:
> Dear sqlite users and developers, > > I am occasionally receiving SQLITE_LOCKED in a forking Python > application. Now according to the documentation > http://www.sqlite.org/cvstrac/wiki/wiki?p=DatabaseIsLocked and > http://www.sqlite.org/c_interface.html I should only get this error if > two actions happen on the same connection in parallel (either via > threads or via recursive calls). Since I have no clue why this happens I > reproduced the problem in a small example C program. Find sessiontest.c > attached. > > So compile sessiontest.c and link it against sqlite on a unixoid > platform. Ensure that the filename "sessiontest.sqlite3" is absent and > writeable in the working directory. Run the executable. > > Observed behaviour: > sqlite3_exec(COMMIT): database is locked > sqlite3_prepare: database is locked > > Expected behaviour: > SQLITE_BUSY or no error, but certainly not SQLITE_LOCKED. > On Debian Linux, I get back SQLITE_BUSY. The text error message for SQLITE_BUSY is (due to an historical accident) "database is locked". Perhaps that is the point of confusion. > > Rationale: > My example program first forks and then opens individual connections. So > sharing via file descriptors or threads is not possible. Also my program > does not pass handlers (besides free) to sqlite, so it cannot cause > recursive calls. Therefore SQLITE_LOCKED should never happen. > > System used: > Debian squeeze amd64 libsqlite3-0 3.7.3-1 > Debian sid amd64 libsqlite3-0 3.7.13-1 > > Is this behaviour correct? If yes, why? > > Any proposed workarounds? > > Thanks in advance > > Helmut > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
