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

Re: M3 ahead...

From: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2001-08-08 01:44:14 CEST

Greg Stein <gstein@lyra.org> writes:
> On Tue, Aug 07, 2001 at 11:08:47AM -0500, Jim Blandy wrote:
> >
> > subversion-dev@thewrittenword.com writes:
> > > And how does Apache find out about the transaction ID that is needed
> > > by txn_abort()? Does mod_dav_svn have this info?
> >
> > Ah, a careful reader! I don't know. :(
>
> As I mentioned before, Apache will never call txn_abort unless the *client*
> sends a request to do that (e.g. DELETE the activity).

I can't be sure, but it really sounds like you are confusing Berkeley
DB transactions with Subversion transactions. txn_abort aborts a
Berkeley DB transaction; it has nothing to do with deleting a DAV
activity.

If I understand Berkeley DB correctly, when a process working on a
DB exits unexpectedly, it will leave locks in the shared memory area.
These locks will need to be cleared out.

Now that I think about it, it should be safe for
svn_fs_berkeley_recover to simply abort all pending Berkeley DB
transactions, since (at least in theory) it knows it is called when
nobody else is writing to the database. So it's not necessary to
recover the Berkeley DB transaction ID's.

> There is no way for Apache to know that an SVN transaction needs to be
> aborted. The death of a child process/thread is an insufficient trigger.

For an SVN transaction, this is correct. For a Berkeley DB
transaction (which is what txn_abort works with), however, if a child
dies, then its Berkeley DB locks can certainly be disposed of --- and
must be, I think.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:35 2006

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.