It may help to point out that the word "transaction" is being used for
two unrelated things, here.
Berkeley transactions are what you think they are -- they mean the
same thing in Berkeley DB-speak that they usually mean in database
contexts.
Subversion transactions (or "txns") are mutable trees in which a
client makes changes, either to commit or to update against. In the
case of a commit, a txn is started as a copy of the revision tree that
is the base of the commit, then the client's modifications are made,
then any changes between base and head are merged into the txn (don't
worry, this is not a server-side merge in the bad sense), and then the
txn tree becomes the next revision tree. In the course of doing all
that, *many* Berkeley transactions will be used.
Hope that clarifies things a bit.
-K
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.
>
> > 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
---------------------------------------------------------------------
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