On Tue, Dec 12, 2000 at 09:04:35AM -0500, Jim Blandy wrote:
> Greg Stein <gstein@lyra.org> writes:
> > On Fri, Dec 08, 2000 at 04:33:25PM -0000, jimb@tigris.org wrote:
> > >...
> > > +/* Commit the transaction SVN_TXN in FS, as part of the Berkeley DB
> > > + transaction DB_TXN. This entails:
> > > + - marking the tree of mutable nodes at SVN_TXN's root as immutable,
> > > + and marking all their contents as stable
> > > + - creating a new revision, with SVN_TXN's root as its root directory
> > > + - deleting SVN_TXN from `transactions'
> > > +
> > > + Beware! This does not make sure that SVN_TXN is based on the very
> > > + latest revision in FS. If the caller doesn't take care of this,
> > > + you may lose people's work!
> >
> > There is a race condition here.
> >
> > Assume the FS does the check for the revision, then calls the commit
> > function. In between the check and the commit, somebody else could have
> > called commit_txn.
> >
> > I believe that you want to pass a "base revision" number to the function.
> > Lock the root revision table, check if the base is the latest, commit the
> > change, then unlock the root table.
>
> I don't think that's necessary. Note that svn_fs__dag_commit_txn
> takes a Berkeley DB transaction (as part of a trail) as an argument.
> As long as the caller checks the revision table and calls
> svn_fs__dag_commit_txn as part of the same Berkeley DB transaction,
> things should be fine.
>
> The transaction may deadlock, but that's just a reflection of the
> nature of commits --- you need to abort the transaction, merge, and
> try again.
Right. The key in your response is "abort the transaction [because of a
deadlock]". As long as that happens... coolness!
Just raising a flag because I didn't know that would happen in there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006