> In my low-concurrency, familly-business context, I have no problem at > all setting 3 hours timeout using the built-in function, when the > slowest transaction may only take less than 5 minutes.
With this condition as a 4th one in your list and with 5th one stating that you have less than 30 slowest transactions in 3 hours you have a very low possibility of having SQLITE_BUSY in the application. It still is not 0 (your computer could be heavy loaded with something else, memory consumed almost to the limit and swap is slowing down everything significantly) but it should be too low to think about. You need additional conditions about concurrency because SQLite doesn't guarantee fairness executing concurrent transactions with busy handler involved. In the message linked by Michael poster clearly says that he observed some transactions starting to wait early and finally executed later than other transactions which started to wait much later. So you have to think what is the worst case when some transaction started to wait and another transactions are keep coming and coming and finally 3 hours are gone but there was no chance for the first transaction to obtain necessary lock. Think about possibility of such "luck" and whether you're comfortable in ignoring it. Pavel On Thu, May 13, 2010 at 12:28 PM, Jean-Christophe Deschamps <j...@q-e-d.org> wrote: > > > Let me take a reality check for the case of my own usage. If I > guarantee that the following conditions are all true: > > All R^n (Read-Read-...-Read) atomic operations are enclosed in BEGIN > transactions. > All W^n (Write-Write-...-Write) and RMW (Read-Modify-Write) atomic > operations are enclosed in BEGIN IMMEDIATE transactions. > All connections setup a sqlite3_timeout() much longer than any > transaction in the "system", including background backups. > > Then am I entitled to say that no deadlock will ever occur (barring > catastrophic condition like hardware failure, memory shortage, corrupt > DB and such)? > > In my low-concurrency, familly-business context, I have no problem at > all setting 3 hours timeout using the built-in function, when the > slowest transaction may only take less than 5 minutes. > > _______________________________________________ > 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
