Philip Martin wrote: > Julian Foad <julianf...@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>
