Charles Samuels <char...@cariden.com> wrote: > On Friday, October 22, 2010 4:44:11 pm Igor Tandetnik wrote: >> This sort of works, if a) you change the order of "commit transaction" >> statements (the reader clears off before the writer tries to commit), and >> b) you don't insert too much, so SQLite keeps your changes in the >> in-memory cache and doesn't have to spill to disk. > > Is this supposed to be the case without WAL?
Yes. A writer should be able to acquire RESERVED lock while readers hold SHARED lock. > I see a "database is locked" > error before I even get to the commit. At which point in your process? >> With the latest SQLite versions, there is write-ahead logging (WAL) mode >> designed to support exactly your scenario: http://www.sqlite.org/wal.html > > I tried it with WAL enabled, and the behavior is the same: > > #include "sql.h" > int main() > { > Sql db; > db.open("db"); > db.exec("PRAGMA journal_mode=WAL;"); > db.exec("create table if not exists x(a)"); > > Sql db2; > db2.open("db"); You likely need to enable WAL on both connections. > db.exec("begin transaction"); > db2.exec("begin transaction"); > db2.exec("select * from x"); > db.exec("insert into x values('a')"); Where are the commits? Try this with raw SQLite API, or show exactly what SQL::exec looks like. -- Igor Tandetnik _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
