Uploaded to CPAN are DBD::SQLite 1.05 and DBD::SQLite2 0.33
Changes for DBD::SQLite2:
0.33
- Set HAVE_USLEEP appropriately. This massively improves
concurrent access to your SQLite DB.
Changes for DBD::SQLite:
1.05
- Enabled HAVE_USLEEP where available which should massively
improve concurrent usage of DBD::SQLite
- Update to sqlite 3.0.6
What happened here was we had concurrency problems with our SQLite databases. I had no idea why. A colleague finally got around to writing a test for it to replicate the problem - this is truly the only way to fix a problem like this. Once the test was written it was fairly easy to figure out the problem (resource starvation due to sleeping too long after a failed lock) and fix it.
Anyone who has had problems running DBD::SQLite on a web server due to concurrency issues should try this version.
I've had concurrency issues with the first DBD::SQLite on a very large database on an NFS mount. But I assumed it was a faulty NFS setup. Haven't seen it in a while, either.
Re:NFS mounts
Matts on 2004-09-10T21:57:49
SQLite on NFS is a complex issue. It's not entirely safe. The locking it performs is not NFS safe and doesn't check for stale NFS locks. This is problematic. On the other hand we're running SQLite on NFS with some success. You do have to make sure your NFS setup is VERY stable though.
Re:RT
Matts on 2004-09-10T21:56:30
That would be nice. We run RT on MySQL, and it's a pain worrying about backup issues. With SQLite we'd just be backing up one file.
I spent most of yesterday tracking down what a race condition in our authentication code that turned out to be a bug in Apache::Session. I have a renewed awe for people who can get their head around concurrency issues. And yet, there are still some people who keep telling me that threads are simple!
-Dom
