On Thu, Aug 15, 2013 at 4:20 PM, Richard Hipp <d...@sqlite.org> wrote:
> On Thu, Aug 15, 2013 at 3:39 PM, Gary Weaver <garyswea...@gmail.com> > wrote: > > > > > Is there anything that stands out as something that would keep 30 > > processes from being able to concurrently insert into the same tables? > > > > Yes. SQLite does not (and has never) supported that. Multiple processes > can read from the same database at the same time, but only one can be > writing at any given time. Multiple writers have to take turns. > > SQLite serializes the writers using posix advisory locks (on unix) by > default and unless the application has done something unusual to disable > the locking. But posix advisory locks are sometimes broken on network > filesystems. Is the database being stored on a network filesystem? > > Richard, their response was, "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'm going to stop on this for now, because it sounds like SQLite was never intended to support concurrent writes to a file DB from what you said, so there is no use trying to debug an use case that isn't supported. I am a little surprised about this behavior, so I would think others might run into it also, but I understand there are limitations and scope to any project. -Gary > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
