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

Reply via email to