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

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

> 1.) clients connect to a socket (AF_UNIX preferred, AF_INET okay).
>
> 2.) the listening on the socket forks of a child to service
> this connection, which is used for an entire transaction (and
> possibly more than one transactionj).
>
> 3.) the child then reads queries from the client, executes them,
> and writes the results back. If the client dies, the child detects
> this easily, and rollsback the outstanding transaction, releases
> locks, and exits.

A standard Unix fork/exec server.

> The code for this child process is extremely thoroughly QAed

That's a red herring, all Subversion code is reviewed. Expecting, or
relying on, one part to be "thoroughly QAed" doesn't really help.

> 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
> before).

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.

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