This is what is says on the SQLite site: "We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once."
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? -- View this message in context: http://www.nabble.com/SQLite-Suitability-for-Shopping-Cart-tp25530589p25606892.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
