Simon Slavin wrote: > On 10 Sep 2009, at 12:02am, Iker Arizmendi wrote: > >> The assumption being that a lock facility that can handle these issues >> is needed by any concurrency scheme (MVCC, shadow pages, etc) and so >> can >> be thought about independently. Does the ability of a client-server >> DB to >> support multiple writers follow solely from the fact that it >> centralizes >> the lock bookkeeping and that it can easily detect death of its >> children? > > 'Death of children' is an issue in some DBMS systems (like SQLite > currently is), but not others. In particular, if you are using MVCC > correctly, death of children hardly matters at all. All it means is > that the DBMS engine will be using a little extra memory (and no extra > processing power) until it decides that a child which hasn't done > anything for an hour is probably not going to come back to life. > > Read up on MVCC. Read up on how to support ACID in a multiuser > concurrent system. Neither allow a client to explicitly lock > anything. Locks are handled by low-level processes inside the engine > and last fractions of a second. > > Simon.
Even with MVCC write locks need to be kept somewhere so it does not address the problems that are resolved by a persistent server process. In any event, (I think) SQLite uses write ahead logging and infers the death of a writer by the presence of the rollback journal so this is the scenario of interest. Iker -- 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
