Hi Jay, > > Invoke sqlite3_busy_timeout() with a safe timeout for every connection > > to the DB. > > Use IMMEDIATE transactions everywhere. > > > > That's all you have to do. > > Well, yes and no. You still have to deal with the case of > SQLITE_BUSY being returned due to deadlocks. Setting a timeout and > using BEGIN IMMEDIATE will help significantly, but not completely > eliminate this issue. It also means that if an SQLITE_BUSY does slip > through, you have no choice but to rollback the transaction and start > all over. > > For more specifics, see: > > http://sqlite.org/lockingv3.html > http://sqlite.org/c3ref/busy_handler.html <= deadlock info > http://sqlite.org/c3ref/busy_timeout.html
I'm not sure you can get deadlocks with immediate transactions. As I understand it, it would defeat the purpose of immediate transactions. Do you have a sample test pseudo-code to show how it can happen? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
