Keith Bostic wrote:
>>From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
>>
>>
>>You're optimising the error case here, which I thnk is a bad idea. In
>>general I'd expect gen#1 processes to be aware of this automatic
>>recovery scheme and to exit gracefully.
>>
>>
>
>I don't expect them to exit gracefully.
>
>Running processes are likely to get a DB_RUN_RECOVERY return
>from a Berkeley DB API call as a result of recovery being run
>on their database environment. It's expected applications will
>simply exit on DB_RUN_RECOVERY returns, there's no reason for
>the application to try and unwind its stack and exit gracefully.
>
>
Is that really the expected behaviour? Hm. Subversion certainly tries to
close the DB environment before exiting.
>That's why recovery exists, to clean up that kind of problem.
>
>Imagine an application suite with 100 processes. One fails,
>and 99 simply exit after receiving DB_RUN_RECOVERY. We're
>going to recover the database environment 99 extra times...
>and then 99 extra times for the processes caught in the second
>recovery run... and so on and so forth.
>
>
I'm not exactly pleased by the loss of an invariant for sanity checking.
Oh well. Let's do it this way and see what happens.
By the way, is there any way to get at the BDB development sources, or
will you post snapshots for testing?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 26 21:40:18 2004