> More sophisticated programs that want more control can still > have it, even with check-in [1879]. If thread A is trying > to COMMIT and thread B is trying to UPDATE, you will get > a busy handler callback from thread A and an SQLITE_BUSY > reply from thread B. But the SQLITE_BUSY return from thread > B did not clear any locks. There is nothing that prevents > the program from rolling back thread A then reissuing the > UPDATE statement of thread B.
OK, maybe I'm just not getting something here, but why on earth would I want to roll back a commit in order to allow an update? Shouldn't it be the other way around? If thread A has completed it's update, and is now in the process of committing that change, why does that *not* take precedence over a thread that is just now starting it's update?
