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

Re: mod_dav_svn and multiple apache processes

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 10 Dec 2009 12:58:23 -0500

By the way, Viacheslav and I brought this closer to closure privately.

C. Michael Pilato wrote:
> Yes, mod_dav_svn may open and close BDB databases multiple times over the
> course of a commit.
>
> HTTP/WebDAV is a stateless protocol. "Stateless" means (in this case) that
> a commit -- which consists of many client->server requests (OPTIONS,
> MKACTIVITY, PROPPATCH, CHECKOUT, PUT, COPY, MERGE, ...) and their responses
> -- happens in phases, each phase carrying enough information to remind the
> server of what the previous phases accomplished (and/or how to figure that
> out for itself). Because of this, you could theoretically shutdown and
> restart your Apache server between each and every request of a single
> Subversion commit operation, and things would work just fine.
>
> I think you are confusing a number of concepts: the HIGH-LEVEL SVN COMMIT
> OPERATION, which happens using one or more CONNECTIONS to the Apache server,
> through each of which one or more REQUESTS is sent and responses received,
> all of which work to make piecemeal modifications to a single SUBVERSION
> REPOSITORY COMMIT TRANSACTION. Until to understand those elements, not much
> more of what I say is going to make very much sense.
>
> Viacheslav Zholudev wrote:
>> Hi Michael,
>>
>> I had a closer look and I figured out the following. SVN may open and
>> close BDB databases MORE than once during ONE svn commit (i.e. during 1
>> svn transaction), and create svn_fs_t objects multiple times. Is it
>> normal behavior? Could it be because Apache decides to clean caches, and
>> then recreates an svn_fs_t object since the previous one was cleaned up
>> and closed? As far as understood from your former emails, only one cached
>> svn_fs_t object should be used by mod_dav_svn PER 1 svn transaction (e.g.
>> commit). But I'm seeing the opposite situation...
>>
>> Could you please clarify? Thanks a lot for your time.
>>
>> Best, Vyacheslav
>>
>>
>> On Dec 2, 2009, at 4:01 PM, C. Michael Pilato wrote:
>>
>>> Viacheslav Zholudev wrote:
>>>> thanks for the answer. It sufficiently clarifies things for me.
>>>> However, I have one more question: Let's assume that SVN client
>>>> commits two big files in the same SVN transaction. Could it happen
>>>> that mod_dav_svn writes pieces of those two big files to the
>>>> "strings" simultaneously? I.e. part1_file1, part1_file2, part2_file1,
>>>> part2_file2 or in some other mixed order?
>>> Today's Subversion clients won't do that. They serialize the
>>> transmission of file contents towards the server. But putting that
>>> aside, the BDB code keeps one file's contents in the 'strings' table
>>> separate from another's by assigning the contents to different database
>>> keys. So while a single client may not write to two different files in
>>> the same transaction, it's certainly the case that multiple clients
>>> could be tossing file contents for multiple files into the 'strings'
>>> table simultaneous. The code does the right thing though -- it's not
>>> like you're going to get corruption or anything that appears like a
>>> file has interleaved content from various sources.
>>>
>>> What's the source of your interest? Are you seeing a problem?
>>>
>>> -- C. Michael Pilato <cmpilato_at_collab.net> CollabNet <>
>>> www.collab.net <> Distributed Development On Demand
>>>
>> Best, Vyacheslav
>>
>>
>>
>
>

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2429271
Please start new threads on the <dev_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe_at_subversion.apache.org>.

Received on 2009-12-10 18:58:44 CET

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.