Re: mod_dav_svn and multiple apache processes

"C. Michael Pilato" <[email protected]> Thu, 10 Dec 2009 12:58:23 -0500
Newsgroups gmane.comp.version-control.subversion.devel,gmane.comp.version-control.subversion.rapidsvn.devel
Organization CollabNet, Inc.
Message-ID <[email protected]>
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 <[email protected]> CollabNet   <>
>>> www.collab.net   <>   Distributed Development On Demand
>>>
>> Best, Vyacheslav
>>
>>
>>
> 
> 


-- 
C. Michael Pilato <[email protected]>
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 <[email protected]> mailing list.
To subscribe to the new list, send an empty e-mail to <[email protected]>.
signature.asc (application/pgp-signature, 197 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkshNr8ACgkQokEGqRcG/W4E3gCeLWfx/lwMrbH66dk2KBwcHIm3
qcsAn3avAMIkf3lbH9FZwzgNea8ZP125
=dD92
-----END PGP SIGNATURE-----