Hello, you should ask that on the php stream, they would probably know better about their wrapper implementation.
try catching up with Ilia. Best Regards On Tue, Mar 18, 2014 at 4:49 PM, Tim Streater <t...@clothears.org.uk> wrote: > Part of my app will, at user request, read some data from an SQLite db and > also some files from disk, and send it all out on the network. This may in > some cases take several minutes, at the end of which the db gets updated > here and there. While this is happening, the user may wish to do another > action that will require read/write access to this db. Typically this will > be another process. > > As it happens I'd not tried exactly the above until yesterday, at which > point I got "database locked" after my timeout period expired. Although I'm > careful to finalize() and close() as appropriate, the way things are > structured at present the database is left open while the slow processing > (writing to the network) takes place. > > I can rejig this without too much trouble, but for various reasons it's > not just a simple case of "closing the db earlier", and so I'd like to be > sure I understand how things work before starting. I'm using PHP's sqlite3 > class rather than PDO, and I've done nothing explicit about the journal > mode. > > My questions are: > > 1) I start with $dbh = new sqlite3 ($dbname); Am I right in thinking that > this does not explicitly open the db (and hence acquire a lock), but that > the db is opened and the default lock (SQLITE_OPEN_READWRITE | > SQLITE_OPEN_CREATE) is acquired only when the first query is done? > > 2) If I want to use a different flag such as SQLITE_OPEN_READONLY do I > need to do an explicit open such as $dbh->open ($dbname, > SQLITE_OPEN_READONLY); or is there a way to specify the flag(s) with "new > sqlite3" ? > > 3) Is the lock always released if I do $dbh->close(); ? > > 4) Would it just be simpler to switch to WAL mode? > > My rejigging would involve closing db's when I'm about to do something > potentially slow and then and re-opening them later but I don't think that > would cause significant overhead. > > > > -- > Cheers -- Tim > > _______________________________________________ > 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