"Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> writes: > Stefan's patch to make a recursive proplist much more performant > highlights the great benefit that our sqlite-backed storage can have. > However, he reverted it due to concerns about the potential for > database contention. The theory was that the callback might try and > call additional wc functions to get more information, and such nested > statements weren't healthy for sqlite. We talked about it for a bit > in IRC this morning, and the picture raised by this issue was quite > dire.
It's not the nested statements that are the problem, it's extending the duration of the select. The callback is to the application so it could be updating a GUI, interacting with the user, etc. and so could take a much greater length of time than other selects. An SQLite read blocks SQlite writes by other threads/processes, so the long lived select may cause writes to fail that would otherwise succeed. (We have a busy timeout of 10 seconds so that's the sort of time that becomes a problem.) It's related to the problem of querying the working copy while it is locked. In 1.6 it was possible to run status, info, propget, etc. while an update was in progress. In 1.7 that's no longer possible, all the read operations fail. If we decide that this change in behaviour is acceptable then the long-lived select isn't really a problem, it simply stops the operations like update from starting. If we want the 1.6 behaviour then the long-lived select becomes more of a problem, as it makes update much more likely to fail part way through. The callback is not necessarily wrong, it depends what sort of behaviour we are trying to provide. -- Philip
