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.
Received on Sat Oct 21 14:36:16 2006