"Bill Tutt" <email@example.com> writes:
> Well, we must do something.
> Alternative suggestions that do solve the problem are certainly
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
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
$ kill xxxx
$ kill -9 xxxx
Now run BDB recovery and clear the lock
$ svnadmin recover /path/to/repository
That provides a secure recovery process, in the face of Subversion
clients and servers. Obviously a user could write a program that
bypasses svn_repos_open if they have sufficient OS/filesystem access,
but then they can also use raw BDB calls, normal stdio, or a normal
editor! If you are concerned about such cases, they are handled by
the usual OS security measures.
At this stage I would argue that we have a "completly and utterly
robust" system. Once a transaction has been committed it is secure,
it will never be lost.
Now suppose you want also want to run BDB recovery automatically. I
probably would not do that myself, but no matter. Can we use Apache
to do this? I'm not an Apache expert, but it does have a controlling
process that remains in communication with it's children. Could we
provide an Apache module, or a mod_dav_svn directive, that causes
Apache to detect children that disappear by dumping core, or children
that hang and become unresponsive? Then Apache could then lock the
repository to block new children, terminate any existing mod_dav_svn
children and finally run repository recovery.
Then, to have a system that automatically recovers a locked database
you run Apache and only allow access through ra_dav.
Is this possible? Does it satisfy your ACID requirements?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Sep 20 12:29:49 2002