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-----