On 20 Dec 2011, at 5:21pm, romtek wrote: > I'd done some research into this since I asked my question and learned > some things. According to http://bugs.php.net/bug.php?id=38182 and > http://www.serverphorums.com/read.php?7,118071, PDO_SQLITE defaults to > a 60 second busy timeout. This should be enough.
Agreed. Certainly an unexpected pause of more than 60 seconds. The default of 60 contradicts something I was told, but that might have been for a different version of PHP. >> Second, most transactions and locks in SQLite from PHP are fleeting. >> Generally you want your web page to list some records or do one update. You >> wouldn't have a process keep a lock active for a long time because this >> would correspond to your server taking a long time to show a web page, and >> nobody wants that. So a lock by one process probably isn't going to last >> very long -- probably a fraction of a second. Access for a web page is >> unlikely to involve deadlock because of the nature of web pages: they >> generally don't interact with the user while a transaction is open. > > > One would think so :) But Drupal people have run into the opposite > (http://drupal.org/node/1120020 and > http://stackoverflow.com/questions/6108602/avoiding-locked-sqlite-database-timeouts-with-php-pdo). > This seems to happen for them mostly when they are indexing their data > a visitor to a site requests a page. Apparently, their indexing tasks > is long running and write intensive. I think they should rework this > tasks. Not sure why someone would start a long-running blocking process for an application which purports to be running. When I do this I give the application a status so it just knows not to try accessing the data file until the blocking process is finished. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
