On Thu, 19 Nov 2009 06:51:05 -0800 (PST), presta <harc...@gmail.com> wrote:
> >According to the documentation : > >"database connection in read-uncommitted mode does not attempt to obtain >read-locks before reading from database tables as described above. This can >lead to inconsistent query results if another database connection modifies a >table while it is being read, but it also means that a read-transaction >opened by a connection in read-uncommitted mode can neither block nor be >blocked by any other connection." > >Correct me if I'm wrong but if the "shared cache" access is locked for each >sqlite3_step, so it's not possible to have inconsistent query results.. and >no possible "real" parallel read/write. The "duration" of a sqlite3_step() is one row, not one statement, let alone one transaction. The reads and writes are interleaved. A SELECT in read-uncommitted mode will retrieve consistent rows, but the result set as a whole is not consistent: it may contain rows which are already deleted by the writing transaction, and not contain rows that aren't inserted yet. -- ( Kees Nuyt ) c[_] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
