> 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. >
I'm all for finer grained lock management as long as it doesn't mean the loss of some important aspects of SQLite that I particularly like. For example, I remember back when I was doing something in MS SQL, the only way to get speeds that I could deal with, was to use pure transactions, which was fine. But I found that a transaction had to complete before I could get result sets back. While I can understand this in a finer grained lock type of SQL, it became somewhat a task to work around the fact that if any SQL errored in the transaction, you had no real way of figuring out which line errored in the transaction. Now, this was many years ago, and my understanding of the API might not have been up to par, but I recall working with a DBA that said to me, "Just make sure all your SQL statements are perfect before throwing them into a transaction.". This made me feel like I had to work around the database, where really I wanted the database to work around my code. The transaction was not a set number of statements, basically what was being done was there was a collection of SQL statements over 200ms, then a commit, so the transaction was actually very dynamic. And from what I can recall, I had a terrible time figuring out which SQL statement in the transaction actually caused the error, not to mention no result sets were returned because of that one error. In the end I had to ditch this method of doing things and port a lot of code into tedious compiled SQL functions, which really made me feel like I had to work around the database. Now this was many years ago, but that was one miserable SQL experience that I hope never to repeat. Jay Macaulay --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
