[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-05-22 20:57:20 CEST

Garrett Rooney writes:
> On 5/22/06, Peter N. Lundblad <peter@famlundblad.se> wrote:
> > Malcolm Rowe writes:
> > > On Mon, May 22, 2006 at 08:24:08AM -0500, Ben Collins-Sussman wrote:
> > > > over DAV opens up the possibility that multiple httpd processes might
> > > > be attempting to write to the same fs transaction at the same time.
> > > >
> > >
> > > >From what I can remember, it certainly looked to me like the FSFS code
> > > requires that a transaction is only updated by a single thread.
> > >
> > > For example, when we receive a text-delta for a file, we just stream the
> > > resulting delta to the end of the proto-rev-file (of which there is only
> > > one per transaction), and that certainly won't work if two callers call
> > > svn_fs_apply_textdelta() simultaneously on the same transaction root.
> > >
> > Yeah, and the same is true for the changes file, for example. I don't
> > think concurrency is supported at all for a single transaction in
> > FSFS.
>
> 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.
>

Or just prevent a transaction to be open my multiple processes/threads at
the same time. At least when you're in the process of applying a text
(delta), doing other write operations to the transaction before that's
done is forbidden by the API. Is it our responsibility to serialize
access in such cases? If not, bailing out on multiple access instead
of producing corrupt transaction is what I'm proposing.

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 22 20:57:52 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.