Greg Stein <gstein@lyra.org> writes:
> On Sat, Aug 04, 2001 at 01:30:58AM -0500, subversion-dev@thewrittenword.com wrote:
> > On Fri, Aug 03, 2001 at 11:36:04PM -0500, Jim Blandy wrote:
> > > subversion-dev@thewrittenword.com writes:
> > > > Unless you're doing locking, I think the chances for encountering
> > > > DB_RUN_RECOVERY are minimal. What does subversion do if a
> > > > transaction has begun (txn_begin) and a signal interrupts the server
> > > > before txn_commit() or txn_abort()?
> > >
> > > Whatever resources were held by that transaction hang around, locked,
> > > indefinitely, until they're cleaned up. Since Berkeley DB has no
> > > reliable way to know when a database client has exited, it can't clean
> > > up after it. The parent process (Apache) needs to notice when
> > > children die ungracefully, and clean up.
>
> A single child dying does not imply that a transaction needs to be cleaned
> up. A given transaction could be performed across multiple children over a
> period of time. Moreover, if the child dies (and the connection aborts),
> then the client "should" potentially retry the operation, meaning that you
> want that transaction left alone.
We were talking about Berkeley DB transactions, not Subversion
transactions.
Berkeley DB transactions can (I think) be used by more than one
process, but that would require them to be a visible piece of the FS
interface, which is bogus. Berkeley DB should be an implementation
detail of the FS --- even if we have to make weird recovery procedures
part of the published interface. :(
> Now... back to the original question: DB_RUN_RECOVERY. If that error ever
> appears during our operation, then we will simply bail out, as usual. That
> particular sequence of operations (e.g. the HTTP request) will terminate,
> needing to be restarted by the client (at its discretion).
>
> Instead, we handle DB_RUN_RECOVERY at the point where the DB is opened. If
> we see that error, then we take out a lock, run the recovery process, and
> release the lock. The lock is used to shut out users of the DB while the
> recovery is occurring. Note that this implies that we always go for a
> "reader" lock every time we open the DB. Multiple readers, single writer.
>
> This is all presumed on the idea that we will see DB_RUN_RECOVERY when we
> attempt to open the DB. If the error only occurs on *operations*, then we
> would need to place the writer-lock-then-cleanup operation on the error exit
> codepaths.
I think we'll see it when we open the DB. We'll play it by ear.
---------------------------------------------------------------------
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