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

"Glenn A. Thompson" <gthompson@cdr.net> writes:

> > One thing we need to do is ensure that the BDB recovery process is
> > robust. The documentation requires that no other process is using the
> > database when you run recover. At the moment we don't have a way to
> > ensure that. What we need is a filesystem lock in the db directory,
> > such that when it is present svn_repos_open fails. Then the recovery
> > process is
>
> I thought that db.lock was used for this purpose.

No idea, I'm not a BDB expert.

> I thought svnadmin aquires an exclusive lock on for recovery and repos
> grabs a shared lock on open.

svnadmin doesn't do recovery, we run db_recover for that. I was
proposing to add an svnadmin command that does a bit more checking.

This is the behaviour I observe at present.

$ svn import URL path
^C

The database is now "stuck". If I was running another svn command at
the same time, then it hangs. If I start a new command that also
hangs.

$ svn ls URL
This hangs.

Now I run db_recover. It doesn't block. So the recovery runs despite
the hung processes. This violates the recommended recovery procedure
in the BDB documentation. While I can check and kill processes before
running recover, I cannot guarantee that another will not start. Hence
the procedure

$ svnadmin lock repo
Now no new processes can open the database.

$ ps
Kill any existing processes.

$ svnadmin recover repo
This is the only process accessing the database.

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