>From http://www.sqlite.org/lockingv3.html:
-------------------------------------- Eventually, the writing process will want to update the database file, either because its memory cache has filled up or because it is ready to commit its changes. Before this happens, the writer must make sure no other process is reading the database and ... ... Obtain a PENDING lock and then an EXCLUSIVE lock on the database file. If other processes still have SHARED locks, the writer might have to wait until those SHARED locks clear before it is able to obtain an EXCLUSIVE lock. -------------------------------------- I believe this waiting by writer has some timeout and eventually he will get "locked" error if reader doesn't release its SHARED lock for a long time. Pavel On Thu, Jul 2, 2009 at 9:38 AM, Tino Lange<tino.la...@interactivedata.com> wrote: > Hi all, > > I have written a program that opens a SQLIte3 database and writes in it most > of the time via replace/update. > > If I do select like (no writes, really only reads) statements from some > other process that carefully opens the database with "sqlite3_open_v2(..., > SQLITE_OPEN_READONLY, ...)" the main (writing) application might get > errcode=5 ermmsg='database is locked' errors when it tries to write while > the other application (only!) reads. > > How is that possible? How to prevent? > > I would expect that the reading application might (of course) sometimes get > "database is locked" errors, but the writing application should never. > > [ I have also realized that the sqlite3 commandline tool uses sqlite_open() > and always opens in read/write mode. That's why I wrote my own reading > application using sqlite3_open_v2 ] > > Thanks > > Tino > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
