Re: #739: Ensuring ACID in Subversion (aka watcher procecesses are fun)

mark benedetto king <bking@Inquira.Com> writes:

> > Lock the repository so that new processes fail to open it
> > $ svnadmin lock /path/to/repos
> >
> > Now check for existing processes that are using the DB
> > $ ps
> > $ lsof
> > $ kill xxxx
> > $ kill -9 xxxx
> >
> > Now run BDB recovery and clear the lock
> > $ svnadmin recover /path/to/repository
>
> What happens when svnadmin crashes after obtaining a lock?

It probably means you need to catastrophic BDB recovery.

> You've got a stale lock file.
>
> If you handle stale lock files by rm'ing them, we're back
> into a lock-stealing scenario (how do you really know the
> lock is stale?)
>
> A user can know that no one else is mucking around in his WC.
>
> An administrator frequently isn't quite so sure that no one
> else is working on *exactly the same problem*.

I was assuming that it would be like

$ svnadmin lock repo
$
OK, I can work on fixing this.

$ svnadmin lock repo
svnadmin: error: already locked
$
Oh! Someone else is doing something.

> It's a secure recovery process, but it's a manual recovery process.
> Personally, I don't want to have to run the command sequence above
> every time someone hits ^C on their client. I'd much rather the
> recovery process only be needed in the case of power-outage.

Yes, but we are going to fix the client to handle ^C. I don't want
BDB recovery to run at all, whether manually or automatically, if
someone hits ^C, as that involves other clients failing.

> I think that requiring manual locking, ps-ing, kill-ing, recovering, etc
> does not meet this definition of robustness.

Well, I disagree :)

I think the plans I have seen so far, to automatically kill clients,
are far less desirable. I haven't seen one that looks to be
particularly robust.

BDB recovery won't need to be done that often. If it is we've got
something wrong.

Finally bear in mind that depending on what has happened, BDB recovery
may fail. In which case you need to do catastrophic recovery, which
will almost certainly require manual intervention.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org