Yuriy, Thanks for following up. Henrik of TravisCI had said that "We do not use network filesystems by default. We do use ramfs for some databases, but I don't think SQLite would use ramfs by default unless you put the database in an odd location. I'm also fairly sure we don't disable locks in any way."
I did a little more research by running some commands in the vm during testing, and here is more info about the environment and filesystem it is running in: $ sqlite3 -version 3.7.9 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e $ uname -r 2.6.32-042stab061.2 $ cat /proc/version Linux version 2.6.32-042stab061.2 (root@rh6-build-x64) (gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Aug 24 09:07:21 MSK 2012 $ lsb_release -a Distributor ID: Ubuntu Description: Ubuntu 12.04.2 LTS Release: 12.04 Codename: precise So it looks like an Ubuntu 12.04.2 LTS VM running on a Blue Box server which is running Redhat 4.4.6-4. (note: the home dir it is running in is within the / mount.) $ cat /proc/mounts /dev/simfs / simfs rw,relatime 0 0 ... $ mount /vz/private/6062841 on / type simfs (rw) ... More info (very limited) on the Blue Box hosting: "Blue Box leverages an assortment of open source technologies including OpenStack, EMC Razor and Opscode’s Chef alongside Blue Box intellectual property and technologies.": https://bluebox.net/press-releases/travis-ci https://bluebox.net/technology http://redhat.sys-con.com/node/2586422 OpenStack storage (assuming that is what they use?): http://www.openstack.org/software/openstack-storage/ If using OpenStack, more info on build: http://www.turnkeylinux.org/blog/announcing-openstack-builds I don't help manage TravisCI, so I'd have to relay questions about anything else. On Sat, Aug 17, 2013 at 12:55 AM, Yuriy Kaminskiy <[email protected]> wrote: > Gary Weaver wrote: > > On Aug 15, 2013, at 3:47 PM, ibrahim <[email protected]> > 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 > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
