It looks to me that several users are (a) in a uniprocess environment, and (b) inventing their own SQLite db access synchronization code. An SQLite fine grained lock manager for threads in a single process would address these same issues, with better concurrency as well.
Jay said: > All database access is handled in a single thread which > synchronizing DB access so that only one SQL command can happen at a > time. Benjamin said: > The most important change for me is one that I introduced into my > copy: Blocking locks. These are important because there is only an > instant between the last transaction closing and the next beginning. > In this scenareo the poll-based locking mechnism currently used by > sqlite is just not lucky enough to try at that instant. Only > blocking locks with their operating-system support are sufficient to > ensure that the readers get in at all. I also have a situation where > I have multiple writers on the database that can run into the same > problem. Allan said: > We don't ever hit the busy timeout handler. We can't since we > synchronize in our data access layer. Doug said: > .. due to the coarse grained locking, I ended up serializing access > to SQLite in my own uni-process multi-thread bottleneck. Are others in the position of having to create their own SQLite db access synchronization code? e --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
