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

Re: can libsvn_fs handle parallel writes to the same txn?

From: Carlos Alberto Costa Beppler <beppler_at_gmail.com>
Date: 2006-05-23 02:43:25 CEST

I donĀ“t know the internals of a commit operation, but is it composed
only of a write operation? The are many tests "reads" that could be
done in paralel, leaving only the "write" part do be serialized. Am I

2006/5/22, Garrett Rooney <rooneg@electricjellyfish.net>:
> On 5/22/06, Ben Collins-Sussman <sussman@red-bean.com> wrote:
> > On 5/22/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> >
> > > Making things work concurrently might be complex, but at the very
> > > least it seems like we should think about adding some locking... If
> > > you're going to append to the prototype rev file you lock it (both
> > > file based and a mutex if you're a multithreaded process, just like we
> > > do for the repos lock), same for the changes file, etc.
> >
> > Yup, this would make concurrent writes to the same txn safe. But it
> > also means that FSFS would never get any of the benefits of
> > parallel-processed commits. There might be multiple httpds all trying
> > to write at once, but then serialized at the fs level.
> Only so long as the actual write is occurring. I imagine there's
> still gains to be had for reading network traffic concurrently,
> preparing to do the write, etc. Not saying it couldn't be made
> better, just that a "slow, but safe" approach seems best at the
> beginning.
> -garrett
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 23 02:43:48 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.