On Tue, Mar 15, 2005 at 12:21:15AM +0100, Thomas Lotterer wrote: > On Sun, Mar 13, 2005, jed wrote: > > > [...] web applications fit well into the model of "many readers, one > > writer", sqlite does this very well. > > > Well, there might be web applications which are read-only from the web's > view. But to be honest, most of them also call for occasional writes. > Think of a simple address book. Also I think of uses like tracking > session cookies which also use occasional writes. In all those cases
I have not tried this with SQLite, but if I was using SQLite for such an app, I assume I would need to serialize all such writes through a single thread or process. E.g., in my web server, the connection thread servicing the user request would send a message to my one single db writer thread, saying, "Heh, please insert this data for me!". Then the conn thread would simply block until the db writer thread replies with, "Yup, your transaction is committed." That is a uglier than what you'd do with a real server-based RDBMS like Oracle or PostgreSQL, but it should scale fine until you have either: One, very large numbers of hits on your simple and efficient web app. Or two, a complicated web app with many potentially long running transactions, etc. In the real world, the second concern is much more likely to bite you than the first, and cries out for a more capable, more general purpose database than SQLite. It would be nice if SQLite had MVCC, which would let it scale much further up into the PostgreSQL-like realm normally dominated by client/server databases, but given the "simple, small, embedded" niche that Dr. Hipp intended for SQLite, it's easy to see why adding MVCC isn't any sort of priority, even if it could be done without making the code much more complicated. -- Andrew Piskorski <[EMAIL PROTECTED]> http://www.piskorski.com/
