The broker has been crashing when the system is under heavy I/O load.
This happens when we get a sqlite3 timeout ("Database is locked") when
executing a "SELECT", as opposed to the earlier "BEGIN DEFERRED".
Reading the docs, this is expected behaviour, and we need to be retrying
the "SELECT" itself rather than the "BEGIN DEFERRED".
A retry is appropriate because there is no appropriate amount of time
after which we should time out. We want to block until the system is
able to process our database query, just like any other command.
Deadlocks are prevented by use of the complemetary _write_lock()
decorator.
I've not added a matching test for this change. The likely area where
this could go wrong is in my understanding of sqlite3's behaviour in
various edge cases, but I can only test that my code meets my
expectation of sqlite3's behaviour rather than what it actually does.
These should no longer be necessary since we changed the algorithm to
determine parents.
The code supporting parent overrides remains for now, for less
disruption to the code base as we near 1.0 and in case this change needs
to be reverted. If successful then the supporting code can be removed at
some point subsequent to the 1.0 release.
These should no longer be necessary due to Launchpad having been fixed
(LP #1881598 and others).
The code supporting pull overrides remains for now, for less disruption
to the code base as we near 1.0 and in case this change needs to be
reverted. If successful then the supporting code can be removed at some
point subsequent to the 1.0 release.
