> What made you expect that? Process A has not entered the exclusive lock and so process B can obtain shared lock to read.
> SQLite allows multiple readers OR a single writer to access the database simultaneously. >From the SQLite doc, as long as no transaction is pending, other process can read or obtain reserved lock for write. On Thu, Jan 28, 2010 at 12:51 PM, Igor Tandetnik <itandet...@mvps.org>wrote: > nyetngoh wong wrote: > > First, I've a process A that do many inserts to the database and reads > back > > from the database to verify. The writes are done in one DEFERRED > transaction > > as data are not committed yet. While the first process running, another > > process B is launched to read from the database for display purposes. > > Process B will halts until the transaction ends. I expect process B able > to > > read the old data and displays appropriately. > > What made you expect that? > > > But, process B seems to be > > blocked. Why is this so as I thought SQLite handle concurrency as in this > > case where there are multiple reads and one single write ? > > SQLite allows multiple readers OR a single writer to access the database > simultaneously. > > Igor Tandetnik > > _______________________________________________ > 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
