> Indeed, it might be very beneficial (for us) if Keith Bostic read the
> whole thread, starting from Jim Blandy's first message. It's pretty
> short, and Jim's questions are clear and pointed.
Absolutely -- we want to help here, so don't hesitate to drag
us in.
> I think the logic in svn_open_repos needs to be:
>
> - get a shared lock on locks/db.lock
> - try calling svn_fs_open_berkeley
> - if it fails with DB_RUN_RECOVERY, then:
> - release shared lock on db.lock
> - get an exclusive lock on db.lock
> - call svn_fs_berkeley_recover
> - release exclusive lock
> - retry from the top
>
> In this arrangement, we only try to recover when we have an exclusive
> lock, and we never return an opened filesystem object unless we have a
> shared lock.
>
> I understand there have been problems with svn_fs_berkeley_recover
> itself returning DB_RUN_RECOVERY. That's pretty confusing; it's kind
> of useless if it does that. But that's not a problem which can be
> swept under the rug, say, by declaring Issue 403 resolved; it's a
> central part of the problem.
Generally you don't want to depend on DB_RUN_RECOVERY being
returned. Detecting corruption is performance prohibitive,
Berkeley DB can't do that. Instead, just always run recovery
if there has been system or application failure.
And, since system or application failure is pretty hard to
reliably detect, it's usually simplest to just always run
recovery in the first thread accessing the database. There is
some discussion on this in the "Application structure" section
of the Berkeley DB Reference Guide, included in the DB download
package and also available at:
http://www.sleepycat.com/docs/ref/transapp/app.html
Recovery should be fast, and if it doesn't need to be run, it
won't hurt you to run it anyway.
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic
Sleepycat Software Inc. bostic@sleepycat.com
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 23 07:30:46 2002