[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: subversion/subversion/libsvn_fs dag.h

From: Jim Blandy <jimb_at_zwingli.cygnus.com>
Date: 2000-12-12 15:04:35 CET

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

This is an archived mail posted to the Subversion Dev mailing list.