Igor Tandetnik wrote: > > Daniel Watrous wrote: >> I've developed an application that has very high concurrency. In my >> initial testing we used SQLite 3 from python, but we experienced too >> many locks and the database always fell behind. > > What precisely is the nature of the concurrency? Are you opening > multiple connections to the same database, or sharing a single > connection between threads? Are you trying to write concurrently, and if > so, is it to the same table or to different tables? > > Basically, there are three ways SQLite can be used (they can also be > combined): > > 1. Many connections to the same database. In this case, there's a > many-readers-single-writer lock at the database level, so at any point > in time only one connection can write. > > 2. A single connection shared by multiple threads. A connection > maintains a mutex that every API call acquires on entry and releases on > return, so all calls are serialized. However, one thread can, say, step > through a select resultset row-by-row, while another inserts row after > row into some table: these calls can interleave, and would appear almost > concurrent. > Hi Igor, So, for "A single connection shared by multiple threads" case, is the statement "there's a many-readers-single-writer lock at the database level" still ture? At least , the read and write would appear concurrent as you said.
Is there any examples showing the difference between these 2 different usage model? Thanks. - Pierr -- View this message in context: http://www.nabble.com/concurrency-differences-between-in-memory-and-on-disk--tp24201096p24266195.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
