Proposals for techniques like MVCC and shadow paging have been made on this list before and they appeared feasible (IIUC) without a server process. The problems with the serverless approach arise once multiple writers are introduced. For example, efficiently detecting crashed writers and initiating recovery. I think this problem may be soluble, at least non-portably, with robust futexes or mutexes. But I imagine there are other issues as well - these are the issues I'd like to get a bead on.
Iker Ken wrote: > The key to increased concurrency is MVCC. Without MVCC concurrency is limited > to page locking, table locking etc. > > Google MVCC... > > --- On Tue, 9/8/09, Iker Arizmendi <i...@research.att.com> wrote: > >> From: Iker Arizmendi <i...@research.att.com> >> Subject: Re: [sqlite] server process gives better concurrency - why? >> To: sqlite-users@sqlite.org >> Date: Tuesday, September 8, 2009, 9:34 PM >> The question is whether a >> client-server design is /necessary/ to >> efficiently implement higher concurrency. It appears to be >> easier >> to do so with a client-server model, but is such a model >> required? >> Are there functions performed by a server process that >> cannot be >> carried out at all without it? >> >> Iker >> >> Simon Slavin wrote: >> > If SQLite was to be >> > designed to handle multiple processes 'properly', it >> would have to be >> > rewritten as a client/server system. >> > >> > This would, of course, kill all the advantages of >> SQLite: it could no >> > longer be tiny, fast, and ultra-portable. So it >> would be a bad design >> > choice for SQLite (bowing, of course, to DRH's right >> to do whatever he >> > pleases with it). >> > >> > This is why I get uneasy when I see posts here that >> suggest spinning >> > off threads especially to deal with locking issues, >> or do other things >> > that solve concurrency or latency problems. >> Often you find that >> > making such a change in your program just leads to >> one of the threads >> > immediately being blocked by another, defeating the >> point of threading >> > in the first place. Software has to be designed >> around what is >> > possible with the tools you're using, not around some >> mythical idea of >> > the perfect generic SQL engine. >> > >> > Simon. >> >> -- >> Iker Arizmendi >> AT&T Labs - Research >> Speech and Image Processing Lab >> e: i...@research.att.com >> w: http://research.att.com >> p: 973-360-8516 >> >> _______________________________________________ >> 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 > -- Iker Arizmendi AT&T Labs - Research Speech and Image Processing Lab e: i...@research.att.com w: http://research.att.com p: 973-360-8516 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
