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

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

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2002-09-20 15:26:15 CEST

Philip Martin wrote:

>>so that it, itself, is unlikely to fail without releasing the
>>locks that it holds. Further, the listener mentioned in (2)
>>can detect when this (extremely rare) failure happens, and DTRT.
>>I think this may be the easiest safe strategy (though it does
>>require a daemon) (which might be auto-started, as mentioned
> What worries me about this proposal is the performance impact on
> mod_dav_svn. We already have a sophisticated server, Apache, where
> the fork/exec stuff has been abstracted into the MPM modules. Adding
> this new server imposes the fork/exec model again. Will this degrade
> (Windows?) servers?
> Aside from the multi-processing issue, I'm also concerned about memory
> usage. Everything into and out of the database now requires memory to
> be allocated in both Apache and the new server. There is also the
> overhead of sending the requests over the local socket.
> Now, ra_pipe will require some sort of svnd server, but that should be
> handling ra requests.

nothing says that this theoretical server has to be used for ALL
filesystem access... (well, maybe bill wants it to be, but personally,
i don't thing it's a 'hard and fast requirement') we could have it only
used for mediating access to the repository for ra_local, and then build
enough smarts into the apache module to deal with similar problems (like
philip theorized about in another email).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 20 15:26:55 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.