[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-09-20 22:38:39 CEST

> From: mark benedetto king [mailto:bking@inquira.com]
> On Fri, Sep 20, 2002 at 11:29:12AM +0100, Philip Martin wrote:
> >
> >
> > 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?
> >
>
> IANAAE, E. :-)
>
> If we only allow access through ra_dav and all of those things can
> be accomplished reliably with apache, then yes, I think it satisfies
> them.
>

Although currently we're not setup to only allow access through ra_dav.
If we did really do that then, yes we'd satisfy the ACID requirements.

Current examples in Subversion where we'd currently violate that
principle:
* svnadmin
* svnlook
etc...

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 20 23:13:08 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.