On 25 Sep 2009, at 6:58am, CityDev wrote: > What that seems to be saying is you can have concurrency but you > will suffer > the effects of whole-database locking for update transactions. It > seems a > glaring shortcoming, so either SQLite is not normally used by multiple > processes or people find it doesn't matter too much ie you still get > acceptable performance with n users. Which do you think is true?
The former. SQLite is the SQL of choice for embedded applications: things running inside a smartphone, or a GPS unit or something. Since these units run just one UI application at a time, you don't need to worry about sophisticated locking mechanisms. Only one processor is used to run user-aware programs. If you're running a program to consult a database of phone numbers or map features or songs, that's the only program that cares about that kind of data. While you're downloading new data for those databases, the entire device is locked in 'synch' mode anyway, so no other programs will be running. Once you've made that design choice, the points Roger mentioned come into play: SQLite library calls are designed to let you do as much processing as possible before you need to lock the file. This is not true of all SQL engines which will do some processing, lock a record, unlock it, do more processing, lock the next record, etc.. SQLite is great for what it's designed for. But it's not designed for complicated multi-user online databases. You pays your money and you gets your choice. Simon. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
