Because thread A is a low-priority background task, and I don't mind if it has to start all over again, while thread B is a high-priority UI thread, and I don't want it to wait. The responsiveness of the system depends directly on how quickly B can get its work done. Thread A will only affect the overall throughput of the system, and I know it will eventually get its chance, so I don't mind if it has to redo a bunch of work.
--Ned. -----Original Message----- From: Brass Tilde [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: [sqlite] Concerns about checkin 1879 > 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?
