-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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.
Did you notice the use of "embedded" several times? The SQLite approach is to use simple locking and to hold locks for as short periods as possible. An alternate approach which would be more complicated locking (pages or rows) and having considerably more code to manage concurrency across processes of that locking. (That code would be really nasty as operating systems don't really provide any common primitives of that level of granularity. Heck they barely provide file locking.) If you go with SQLite's flow such as not having open transactions lying around and getting work done as quickly as possible (eg composing SQL upfront rather than long periods thinking about what to issue next within a transaction) then it will work *very* well. Chances are it will significantly outperform database "servers", as they require marshalling of queries and responses between processes and possibly over the network - something which will be way slower than SQLite's quick transactions. (SQLite was originally started because of database servers being flaky and needing administration.) Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq8apMACgkQmOOfHg372QSH+ACguuHaLxS7CoPE/yjTXrKI/r3u TKYAoNOcv4Gtw9BL6iHsz31DWZQKI8fs =OMAn -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
