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.
NFS mounts (Score:2)
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.
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Re:NFS mounts (Score:2)
RT (Score:1)
Re:RT (Score:2)
Good detective work (Score:2)
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 [cpan.org]. 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