On 16 Aug 2013, at 5:03pm, Gary Weaver <garyswea...@gmail.com> wrote:
> Thanks to you and Richard for the links and info. Concurrency is not > outlandish to expect, especially when it works in OS X and just not in the > Ubuntu vm in Travis, but I now understand that these are expected problems. Worth noting that concurrency works just fine in SQLite if all that accesses are done by directly talking to the hard disk and not using an NFS. In other words you have to do it the way the big server/client DBMSes do it -- MySQL and Progress -- you don't have lots of computers opening the a database file on a remote hard disk, you run processes on the server computer itself and only those try to open the database file. This is what happens with the, I'm sure, millions of web-facing database applications which use SQLite as a back end. You request database action using HTTPS (either through JavaScript or perhaps by using a utility like 'curl' on your computer). The server spawns an httpd process which does the actual file access and returns the results in the HTTPS connection. That's what you get when you write a PHP backend. SQLite's API automatically takes care of serialising concurrent requests, using an algorithm like exponential back-off. It works fine. But it works because all those processes are running on the same computer opening a SQLite database on its own hard disk, rather than remote computers trying to read and write that file using a Network File System. You have promoted the network traffic to the level of API request rather than file reading and writing. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
