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.
> And how does Apache find out about the transaction ID that is needed
> by txn_abort()? Does mod_dav_svn have this info?
Apache will not worry about "garbage" transactions. svnadmin will be used
periodically to find "old" transactions and delete them.
svn_fs_list_transactions() can be used by svnadmin to get the transaction
information.
There is a bit more to clearing old transactions, but the main point is that
it will not be handled by Apache.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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