"Hyrum K. Wright" <hyrum_wright_at_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
Received on 2010-11-30 13:34:19 CET