Philip Martin wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>>> URL: http://svn.apache.org/viewvc?rev=1422042&view=rev
>>
>>> Log:
>>> Fix issue 4210, rep-cache not reseting SQLite statements on error.
>>
>> I noticed the other day that WC DB code in many places fails to reset
>> stmts on error, but that svn_sqlite__get_statement() automatically
>> resets the stmt if it hasn't been reset since last used. Does this
>> tally with your understanding of what you just fixed in the rep-cache
>> -- that is, it could be described as a functionally harmless coding
>> style violation?
>
> I'm not really sure. We go to a lot of trouble to reset statements in
> some places. Perhaps it doesn't really matter in this case because the
> server only uses a small number of statements so there can never be a
> large number of statements needing to be reset?
>
>> If so it would be good to say so in log msg & issue to indicate it
>> doesn't need back-porting.
Bert wrote on IRC[1]:
> Forgetting to reset statements is not harmless... It might cause so
> much trouble that we try to recover from this problem in a few places
> where we can. Forgetting to reset causes the db to stay locked;
> transactions to fail in unexpected locations. In many cases this
> appears harmless for short living processes like svn, but really
> problematic for long living clients.
>
> The problem is that there are so many error conditions in our wc db
> code that we won't be able to cover them all in the test suite, so
> there will always be bugs. And that get statement (and the error
> handling in transactions, etc.) tries to keep things working after
> such bugs.
OK -- so it does matter. I will bear this in mind and maybe do something about it.
- Julian
[1] <http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-12-14#l365>
Received on 2012-12-19 21:41:55 CET