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
