On 20 Dec 2011, at 9:03am, romtek wrote: > On Mon, Dec 19, 2011 at 1:34 PM, Pavel Ivanov <paiva...@gmail.com> wrote: >> >> Yes, this is expected behavior. In this case transaction won't be able >> to ever proceed because it can proceed only when writing transaction >> in session 1 is committed but it cannot be committed until all reading >> transactions are finished, including transaction in session 2. So it's >> a deadlock and SQLite knows about that, thus it returns "database >> locked" immediately. > > Does anyone know if those who use SQLite with PHP need to be concerned > with this issue (i.e. to program around this)? I've assumed that a PDO > driver for SQLite or another layer will take care of waiting, > retrying, etc. when needed. Is that a correct assumption?
First, there's more than one way of using SQLite3 from PHP. There's also the interface SQLite3:: which is a much thinner wrapper around the basic SQLite C library. I have no way of knowing what proportion of programmers use one library or the other. As long as you set an acceptable timeout, which you do with one of these calls depending which library you're using <http://php.net/manual/en/pdo.setattribute.php> <http://uk.php.net/manual/en/sqlite3.busytimeout.php> your web service probably isn't going to run into problems. What might be worrying you right now is the result of the default timeout being zero, something which is arguably weird. In other words, unless you specify a timeout yourself any report of a lock is instantly treated like an error. Set your timeout to one second or five seconds and the behaviour will be more reasonable. 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. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
