Re: svn commit: r1716575 - in /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c

On 26 November 2015 at 11:41, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>> Sent: donderdag 26 november 2015 09:19
>> To: dev_at_subversion.apache.org; Bert Huijben <bert_at_qqmail.nl>
>> Subject: Re: svn commit: r1716575 - in
>> /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c
>>
>> On 26 November 2015 at 11:05, <rhuijben_at_apache.org> wrote:
>> >
>> > Author: rhuijben
>> > Date: Thu Nov 26 08:05:36 2015
>> > New Revision: 1716575
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1716575&view=rev
>> > Log:
>> > In ra_serf: when a to-be committed file has text and property changes to
>> be
>> > applied, pipeline both requests.
>> >
>> This could fail over HTTP/2 if both pipelined requests will be handled
>> by different worker threads: FSFS doesn't allow concurrent access to
>> transactions.
>
> I'm surprised to learn that. I would have guessed concurrent access was
> always part of the design of the fs layer, by the way we use it in mod_dav.
>
> I hope we can somehow lift that restriction, as improving commit performance
> over mod_dav is high on a few wish lists.
>
First of all I'm not sure that concurrent *writing* could speed up
commit: there is no fsync() calls when working with transactions. As
far I remember svn:// also waits for every TXN operation to complete
before sending next one, so svn:// and http:// performance should be
the same when working over high-latency network.

Another problem could be than TXN operations are have dependencies on
each other and order is very important.

-- 
Ivan Zhakov