Ben Collins-Sussman wrote:
> On Thu, Nov 6, 2008 at 1:35 AM, David Glasser <glasser_at_davidglasser.net> wrote:
>
>> There's a lock around appending to the proto-rev file, yes. And it
>> does write a bunch of little files for noderevs, directory listings,
>> and props, and gloms them on at finalization time, yes. But there are
>> no locks around editing the little files themselves; so for example,
>> if concurrent processes make two files in a directory at the same
>> time, there can be a race condition and only one will end up in the
>> listing. This situation isn't possible if you only access a
>> transaction from a single process (say, via the commit editor).
>
> But if all writes go through a single process, that sort of defeats
> the goal of saturating the bandwidth with parallel PUTs. Maybe it
> would be a worthy goal to make FSFS safe? I know it's something we'll
> have to do for libsvn_fs_bigtable.
Having the ability to expose an svn_txn_fs through an HTTP interface would be
very useful. I needed this functionality for an application we're writing and
ended up writing my own RPC layer on top of svn_fs.h to accomplish this.
So I'd rather not see an HTTP interface that you begin a txn, push and commit
all in one step.
I haven't looked at the mod_dav_svn code, but does it maintain a pool of
svn_txn_t's where users of the svn_txn_t's checkout and get one?
When I looked at the fsfs code, there's locking in a single svn_txn_t, but if
you have a multithreaded application that has multiple svn_txn_t's open for the
same transaction, then there's nothing protecting the transaction from
concurrent writes. The fcntl() locks don't protect between multiple threads in
the same process and since you have two or more svn_txn_t's, they don't
synchronize on the same mutex.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-06 18:19:45 CET