Well, I thought that WAL and the old locking mechanisms allowed for concurrent read access. (That's why I thought this would be true for a shared connection as well - which apparently isn't true.)
On Thursday, 20. September 2012 at 15:55, Keith Medcalf wrote: > > Two separate database connection can read concurrently. But you can only > > do one thing at a time with a single database connection. > > > > > You could prepare a select statement, one on each thread, and step them each > in their own thread, against the same database connection, even though only > one thread would be 'stepping' at a time, in much the same way that you can > have fifty programs writing to disk 'concurrently' (yet I/O is serialized so > only one write operation proceeds at a time). > > I think it all depends on how you define "concurrency" ... the database > connection is serialized so no operations occur concurrently, however, you > can execute separate operations against the same connection in separate > threads and all will "make progress" in an interleaved (serialized) fashion > within the constraints of the OS scheduler. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org (http://www.asciiribbon.org) > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org (mailto: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
