On Tue, Apr 3, 2012 at 12:53 PM, Dan Kennedy <danielk1...@gmail.com> wrote: >> As a side note: why does not SQLite automatically retry implicit >> transactions after invoking busy handler? > > It's a race. That's what SQLITE_BUSY means. > > As Jay says, deadlock is not possible for implicit transactions. > SQLite will keep retrying until either your busy-handler returns > zero (if you configured a busy-handler) or the timeout is reached > (if you configured a timeout). It sounds like the latter in this > case.
I don't follow the logic here: if deadlock is not possible with implicit transactions, SQLite should retry them after specified timeout, but not return _BUSY, forcing me into implementing the same retry logic, no? > If you are using WAL mode, check that connections are being closed > properly. If they are not, a *-wal file may be left on the disk even > after all active clients have disconnected. In this case, when the > next client connects it has to read and process the entire *-wal > file. This is called "recovery", and the client holds an exclusive > lock on the db file while it is underway. Any other clients > that attempt to read or write the db see an SQLITE_BUSY. Any > busy-handler (or timeout) will apply here, but if recovery takes a > while then a short timeout could be exceeded. Am I correct that if e.g. I have 2 processes, A and B, using the same WAL-enabled database, then following: 1. A creates the database and starts to write data (connection is open all the time) 2. B tries to connect to the database can easily result in SQLITE_BUSY returned to either A or B? Gregory _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
