My thoughts are that most programmers over use and abuse threading and I love the simplicity of your database as it is. Can't tell you how many C projects that have almost failed because of threading and memory issues (til I took over them and became Mr. Fix man). First thing I did was pull out all the over complexity. I avoid threading as best I can. For some reason everyone equates being smart with being complex, I think it is just the opposite. Being able to solve the problem optimally with as much simplicity as possible.
We are putting finishing touches on a client server application for ship late this year. This application was originally slated to use SQL Server, Oracle, or DB2, but just for grins we tested out Sqlite as the server backend. It worked great. We are so pleased with it that we are not going to ship with support for a large scale RDBMS. Because of our tests we found that realistically we don't need huge scalability and with hardware continuing to get faster, Sqlite continues to get more scalable. We are doing thread synchronization at the data access layer which is well above the database. The system is just as fast as using the large scale except MUCH easier to maintain with Sqlite. And yes, it is just as fast if we don't thread sync at the data access layer. To answer your questions. 1* Don't know, Sqlite is so fast, not concerned with sub second queries! They all seem to run that fast. 2* Minimal use of transactions through design and business logic code, security seems to be the only transaction candidate. 3* One, it is either an application server, web server. These apps have multiple thread handlers but it is all synchronized at the data access layer so only one request can get to the db at a time. 4* We don't ever hit the busy timeout handler. We can't since we synchronize in our data access layer. 5* from minimal 500k - 50 GB (the 50 GB is tested, not in production) 6* All the time. In fact, we found that you get extremely good performance on USB 2.0 connected drives or RAID SCSI systems. Thanks, Allan -----Original Message----- From: D. Richard Hipp [mailto:[EMAIL PROTECTED] Sent: Sunday, November 23, 2003 11:22 AM To: [EMAIL PROTECTED] Subject: [sqlite] Concurrency in SQLite Lots of people seem to think that better concurrency in SQLite would be useful. But I am having trouble understanding why. Please, give me some examples of the kinds of things you are doing which could benefit from improved concurrency. * What SQL are you running that takes more than a fraction of a second to complete? * Are you holding transactions open for an extended period of time? Why? * How many processes do you have trying to access the database at once? * How do you currently handle SQLITE_BUSY replies? Do you use the sqlite_busy_handler() or sqlite_busy_timeout() APIs? * How large are your databases? * Do you ever put database files on a shared filesystem? The better I understand the problems, the better job I will be able to do in resolving them. Thanks for you responses. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
