"D. Richard Hipp" <[EMAIL PROTECTED]> writes: > 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.
It seems that there's a (possibly difficult, depending upon the application architecture) bit of record keeping required in the application to track whether the busy handler was called. Might I suggest that SQLITE_BUSY_NOWAIT (a new error code) be returned whenever a busy condition is detected that does not go through the busy handler; and SQLITE_BUSY be returned after the busy handler times out. In the above example, thread A doing its COMMIT would call the busy handler callback and then, when necessary, return SQLITE_BUSY, while thread B doing its UPDATE, would immediately return SQLITE_BUSY_NOWAIT. There may be a more appropriate name for the new error code... SQLITE_BUSY_LOCKED maybe? Does this have merit? Derrell
