On Wed, Aug 24, 2011 at 9:51 AM, Simon Slavin <slav...@bigfraud.org> wrote:
> On a Mac running OS X 10.6.8 Server. Being accessed by another Mac running > 10.6.8 Client. > > The shell tool I'm using is the one found on a standard installation of OS > X 10.6.8. It accesses the database by opening the file across an AFP > connection to the server. The shell tool can read and write the database > file itself fine. > > The app which is meant to access this database is an Apache/PHP app. It > uses the SQLite3:: object-oriented API to access the database. For > necessary reasons the PHP app opens the database twice: once with > SQLITE_OPEN_READONLY, reads stuff, then closes it, then opens again with > SQLITE_OPEN_READWRITE, reads and/or writes stuff, then closes it. All this > happens very fast, with no pauses for user-input or long processing by > anything apart from the SQLite engine. > > When either the shell tool or the PHP app are used by themselves they work > fine, but I used the SQLite shell tool for monitoring something and while > that tool had the database open my PHP application got errors > > SQLite3::query(): Unable to execute statement: database is locked in > [...]readrec.php > > So my question is ... while the shell tool has a database open across an > AFP connection, do I expect it to prevent PHP from accessing the database ? > Or is perhaps the PHP language giving the wrong error at the wrong time, > opening the database as READONLY when I asked for READWRITE because it > couldn't get READWRITE ? > You've run up against limitations of AFP. Or, more precisely, you've run up against the performance/concurrency tradeoffs that are inherent in any network filesystem. Apple has contributed working (though wildly complex) code that allows SQLite to efficiently read and write database files on AFP filesystems. But this code has the limitation that you can only open the SQLite database on one machine at a time. You can open the same database multiple times on that one machine. But you cannot have the database open simultaneously on two or more machines. One work-around you should try is to ssh into the machine that is running PHP and run the sqlite3 shell from there. I think that will work better for you. You'll get much better performance if you put your SQLite databases on a local filesystem, fwiw. > > I looked at the source code for the shell tool. I'm not good at C, but as > far as I can tell it opens the database file in a sharable manner, not in a > way as to lock it against other apps. I tested this by using two copies of > the shell tool at the same time and the work just fine, both able to have > the database open at the same time and see each-other's changes. So that > doesn't seem to be the problem. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
