On 9 Sep 2009, at 4:35am, Igor Tandetnik wrote: > Iker Arizmendi wrote: >> The question is whether a client-server design is /necessary/ to >> efficiently implement higher concurrency.
Until you specify how high you want to go, it's impossible to figure out if something is necessary. >> 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? > > On a high, theoretical level, the advantage of a single server process > is that it has more context. It knows intimate details about > everything > going on in the system, and can manage concurrent tasks more > efficiently > using this information (e.g. use fine-grained locks). On the other > hand, > multiple cooperating processes share only a limited amount of > information; each process knows very little beyond what it itself is > doing. Also, it requires the client programmers to understand how to exploit the concurrency facilities. They have to write special bits in their software to call the locking routines, etc.. The advantage of not having fine-grained locks is that the programmers just write standard SQL, with BEGIN ... COMMIT, and the DBMS figures out how to implement it. Makes the system usable for programmers who don't have a lot of time to become experts in your particular SQL engine. There's a model for concurrency that /doesn't/ require locks. What happens is that if a user does something that begins a transaction, they get their own private copy of the database. If the transaction ends with COMMIT, the shared version is thrown away and the private version is the new shared version. If the transaction ends with ROLLBACK (or an error) then the private version is thrown away. Under this model nobody ever locks out anyone else. No locking, no waiting, no chance of deadlock. Fantastic. Except that two users can be in the middle of transactions at the same time. So you have to figure out a way to merge two private copies of a database into one. And it may or may not work just to execute the SQL commands you journalled, depending on how you feel updates should work. There's no right answer to the general problem: it's down to what works best for your particular requirements in writing your particular application that uses an SQL engine. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
