A suggestion: the SQLite DB driver could keep a serial number that is incremented whenever the DB is modified by the driver. The driver could then re-open the DB if the file handle it gets from gethandle is stale. It wouldn't work in the case of another process outside the web server modifying the database, but maybe that could be done with a periodic check of the DB file's timestamp.
> > On Wed, Jul 14, 2004 at 02:51:44PM -0400, Dossy wrote: > > > "SQLite version 3.0 is made possible in part by AOL developers > > supporting and embracing great Open-Source Software." > > > > I wonder what this is all about. Anyone know? > > No idea. Sounds interesting, though. :) > > > And, from the FAQ at http://www.sqlite.org/faq.html: > > > | Note that if two or more threads have the same database open and > > | one thread creates a new table or index, the other threads might > > | not be able to see the new table right away. You might have to get > > | the other threads to close and reopen their connection to the > > | database before they will be able to see the new table. > > > Pargraph #3 bothers me. If this is the case (changes in one thread not > > picked up by the other threads unless they close/reopen the DB), that's > > a pretty tough limitation. > > Dossy, like it or not, that's because by design, the ONLY operating > system services SQLite uses for locking are a file locks on the > database file. (More or less; if I remember right, it's actually a > bit more complicated than that, but that's the general idea.) > > For AOLserver use, you basically have two simple options: > > 1. Open and close the SQLite db file for EVERY transaction. This is > the normal way to use SQLite, and is definitely what you have to do if > other processes might also be accessing the same database. > > 2. Keep the database open, and serialize all SQLite operations through > a single thread. > > I would prefer to see an optional single-process many-threads MVCC > concurrency model for SQLite, and several variants of that have been > discussed rather extensively on the SQLite list. But so far no one > has implemented it, and it's rather outside Dr. Hipp's primary design > goals for SQLite. > > SQLite 3.0 introdues some new stuff to improve concurrency, but it > doesn't go nearly as far as full-blown MVCC. That said, the SQLite > wiki has numbers suggesting that the concurrency achievable even with > the older 2.8.x SQLite is probably adequate for many small to medium > websites: > > http://www.sqlite.org/cvstrac/wiki?p=WhenToUseSqlite > > My personal SWAG, is that if you can run your website ok on MySQL, you > can probably run it just fine on SQLite too. > > -- > Andrew Piskorski <[EMAIL PROTECTED]> > http://www.piskorski.com/ > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with > the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field > of your email blank. > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
