On Thu, 24 Sep 2009 22:58:28 -0700 (PDT), CityDev <nab...@recitel.net> wrote:
> >This is what is says on the SQLite site: > >"We are aware of no other embedded SQL database engine that supports as much >concurrency as SQLite. SQLite allows multiple processes to have the database >file open at once, and for multiple processes to read the database at once. >When any process wants to write, it must lock the entire database file for >the duration of its update. But that normally only takes a few milliseconds. >Other processes just wait on the writer to finish then continue about their >business. Other embedded SQL database engines typically only allow a single >process to connect to the database at once." > >What that seems to be saying is you can have concurrency but you will suffer >the effects of whole-database locking for update transactions. That's what is says, and it's a design decision. >It seems a glaring shortcoming, I wouldn't say so. >so either > 1) SQLite is not normally used by multiple processes or > 2) people find it doesn't matter too much ie you still > get acceptable performance with n users. > Which do you think is true? 1) is true. 2) is not false, but doesn't really apply, considering SQLites "mission statement": http://www.sqlite.org/whentouse.html -- ( Kees Nuyt ) c[_] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
