Hello!
I have a concern, primarily related to Justin's new ra_serf stuff and
its effect on libsvn_fs. I'm looking for libsvn_fs experts to comment
and allay my fears.
As I understand it, for read operations, ra_serf is currently opening
a few TCP connections to httpd and simultaneously pipelining bunches
of GET and PROPFIND requests. Justin has said that in the future, he
plans to make commits do pipelining as well.
Now, I know that ra_svn already does pipelined commits -- but it sends
the stream of requests to a single server process, which handles each
request in order. In the case of ra_serf, however, we're talking
about a stateless protocol with no guarantees about the number of
simultaneous open connections. In other words, pipelined commits
over DAV opens up the possibility that multiple httpd processes might
be attempting to write to the same fs transaction at the same time.
Take a hypothetical example. Suppose ra_serf, doing an import,
creates a new directory via MKCOL. After the request completes
successfully, in then opens 2 new connections and pipelines a bunch of
PUT requests over both. The PUT requests all represent sibling files
being created within the new directory. So now we have at least two
httpd processes running svn_fs_make_file() and svn_fs_apply_text()
within the same directory in the same transaction at the same time.
* Can our dag subsystem handle this? There's a bunch of logic
within there about opening 'mutable' paths down to the edited
file, which I guess is our 'bubble up' algorithm. But what
happens when two processes try to create a new file in the same
directory at the same time?
* Are there any other problems specific to either BDB or FSFS that
may make parallel writes break? (Like, say, our 'changes' table?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 22 15:25:00 2006