On 9 Sep 2009, at 9:09pm, Iker Arizmendi wrote: > I'm hopeful that it's possible to devise a scheme that will let > SQLite support > multiple readers and writers while completely preserving all of its > current > benefits (eg, serverless, efficient, zero-conf, simple API, small > footprint).
Sorry but I don't think it is. The amount of code you'd have to add to SQLite to do concurrency correctly and fast is probably about as much code as there already is. It's not a small addon to the existing system. > To that end, I'm trying to understand some of the "sub problems" > that get in > the way of multiple writers in order to take a stab at working them > out. I can > see that the overall problem is nontrivial and an acceptable > solution has not > been found. But this only proves that the problem is hard, not that > it's > impossible (*). I would recommend books with titles like 'DBMS Systems' or 'Principles of Multiuser Database Design' or 'Client/Server Database System Architecture'. Or you might want to sign up for a university course or something. This stuff is hard. One reason SQLite is small, fast, portable is that it does not try to do these things. And the core parts of SQLite might not be easy to adapt to concurrency. It might be simpler to start from the ground up and not support any legacy SQLite facilities. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users