DRH> This is about the bazillionth request for the older 2.8 behavior DRH> that provided less concurrency. I'll try to have a low-concurrency DRH> solution installed in 3.0 by the end of the week.
Well, I wasn't actually requesting a code change, just a suggestion for a work-around the change in behaviour in 3.0 from 2.8. I realize that concurrent access from multiple threads/processes is not a major requirement for SQLite. However, 2.8 was quite usable in this respect. We're upgrading to 3.0 precisely for the improved concurrency but the change in behaviour I described earlier complicates things quite a lot. Using 3.0, every single write to the database now has to handle the possibility of a SQLITE_BUSY and retry multiple times before giving up which is clearly going to be messy. So I was asking if there was something I had missed and an easier workaround. Thanks for all the work.
