> Multiple processes has nothing to do with it, other than the usual > increases in complexity that would be added to any app.
Except that it's much-much easier to implement fine-grained locks working inside one process, not dealing with file system locks and being sure that nobody but yourself will write to the database. Pavel On Tue, Sep 8, 2009 at 8:23 PM, Cory Nelson<phro...@gmail.com> wrote: > On Tue, Sep 8, 2009 at 4:58 PM, Iker Arizmendi <i...@research.att.com> wrote: >> Hello all, >> >> One oft-cited method to address SQLite's limited concurrency support is to >> use a client-server database. Such databases enjoy better concurrency thanks >> to their use of a master, coordinating process which is hard to obtain >> efficiently using unrelated processes like those of SQLite. What's the key >> to this master process's increased concurrency that is difficult to emulate >> using a scheme among unrelated processes? Does the primary benefit of the >> master process lie in its ability to efficiently detect abnormal termination >> of child processes and deal with their locks? > > The reason for sqlite's poor concurrency is due to it using a single > global reader/writer lock. Other dbs usually have much finer grained > page- or row- level locking, and MVCC. > > Multiple processes has nothing to do with it, other than the usual > increases in complexity that would be added to any app. > > -- > Cory Nelson > http://int64.org > _______________________________________________ > 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
