> But I imagine > there are other issues as well - these are the issues I'd like to get > a bead on.
I just keep wondering: do you want to write some new database engine based on SQLite so that it will heed all these caveats? Otherwise this discussion is useless because all these features are not implementable on top of SQLite and are way nontrivial to implement inside SQLite... Pavel On Wed, Sep 9, 2009 at 1:44 PM, Iker Arizmendi <i...@research.att.com> wrote: > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
