Gary Weaver wrote: > On Aug 15, 2013, at 3:47 PM, ibrahim <ibrahim.a...@googlemail.com> wrote: > >> On 15.08.2013 21:39, Gary Weaver wrote: >>> SQLite varies between file is encrypted/not a DB errors and database disk >>> image is malformed. It would seem consistent with SQLite not handling >>> concurrent processing in this particular environment or with the version of >>> SQLite since 3.7.7 is fine in OS X. >>> >>> Is there anything that stands out as something that would keep 30 processes >>> from being able to concurrently insert into the same tables? >> 30 processes being able to concurrently insert into the same tables ??? > > 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.
There are *two* problems above, one is "expected", and one is not. 1) SQLite won't execute any database modification concurrently, they will be serialized internally (or return SQLITE_BUSY error, depending on timeouts). That is, executing requests concurrently won't be any faster than executing them consequently from single connection. And those locks are not fine-grained - they are database-wide, not table or page-wide. And this one is "expected problem". 2) But database corruption is certainly an UNEXPECTED problem: no matter how many processes are trying to access same database, this is not expected to corrupt database. If database was corrupted as result of concurrent access, likely reasons are: FS bug, especially with file locking (e.g. many networking FS [nfs, cifs, etc] are known to be buggy/broken with locking; and anything FUSE-based is likely also problematic), other kernel/drivers bugs, malfunctioning hardware. Of course, "SQLite bug" is also possible, but very unlikely (sqlite is extensively tested in various scenarios, including concurrent access). If you use any "unusual" filesystem, that would be the prime suspect. E.g. if your VM allows transparent access to part of host fs, and you can open connections to same database on host fs from several guests, that's recipe for disaster. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
