You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/09/12 17:00:47 UTC

aborting txns (WAS: Re: state of union)

Greg Stein <gs...@lyra.org> writes:


> > > >  * 484:  ra_dav:fetch.c:reporter_abort_report() must abort txn.
> > > 
> > > DELETE the activity. Of course, the server doesn't understand that, but that
> > > is the correct wire marshalling.
> > 
> > DELETE is part of HTTP 1.1.  Somehow mod_dav_svn needs to interpret
> > this request on a activity url??
> 
> repos.c has a function for deleting things (dav_svn_remove_resource). Right
> at the beginning, it checks the resource type for WORKING. It should be a
> reasonably easy thing to add a check for ACTIVITY, and then to call a new
> function in activity.c which would abort the txn and delete the entry from
> the activities DBM.

Okay, I think this may be a waste of time.  I now understand how
ra_dav is implementing the update reporter vtable:

 RA->do_update()           :   create a tmpfile
 reporter->set_path()      :   write xml to tmpfile
 reporter->delete_path()   :   write xml to tmpfile
 reporter->finish_report() :   tell neon to pull xml data from tmpfile
 reporter->abort_report()  :   remove tmpfile

So here's the deal.  If the client ever needs to call abort_report(),
it will always be *before* it calls finish_report().  (Really,
abort_report() only happens if libsvn_wc stumbles while examining the
working copy.)

Unlike ra_local, when ra_dav gets an abort_report(), no server
transaction has been created yet... there's nothing to clean up!

I think there's no problem to solve here.  The reporting-phase of
updates seems fine over the network.

I must have misdiagnosed the reason we were getting dozens of orphaned
transactions left on svn.collab.net; back when network updates were
failing (due to apache timeouts, etc.), it was always in the middle of
mod_dav_svn sending back a large update response.  I bet that's why
transactions were being left behind.  I bet mod_dav_svn isn't
perfectly cleaning up txns when errors happen.  I'll take a look.  (I
mean, at this moment, we still have 100+ orphaned transactions sitting
in our repository!)


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