I can vagualy tell you without experiment:
- One for the resource
- One for the collection the resource is in
- One for the VHR (if autoversioning is turned on and the resource is put under version control with this request)
- One for the history folder the VHR is in (if autoversioning is turned on)
- One for the versioned resource in the VHR (if autoversioning is turned on)
Oliver
Michael Oliver wrote:
I will also have a look at how many storeRevisionDescriptors occur with a mkCol or put.
Michael Oliver CTO Matrix Intermedia Inc. 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Sunday, July 18, 2004 1:44 PM
To: Slide Developers Mailing List
Subject: Re: Descriptor churn
OK, I see. I will have a look at it ASAP.
Oliver
Michael Oliver wrote:
OZ, I said what I was doing, I was browsing the slide servlet with a
web
browser, NOT a Web Folder or a WebDAV client, yet still all those descriptors were touched.
Michael Oliver CTO Matrix Intermedia Inc. 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Sunday, July 18, 2004 10:09 AM
To: Slide Developers Mailing List
Subject: Re: Descriptor churn
As I already said: Which read-only WebDAV methods are being executed when storeRevisionDescriptor gets called? If you provide this I
promise
to persue it.
I would be really surprised if there are modifications inside
read-only
methods, though...
Oliver
Michael Oliver wrote:
That's just it, no WebDAV modifications need be done to see calls to storeRevisionDescriptor and here is a test I just ran to show it.
I used a web browser to hit my slide, logged in as root and navigated
to
/files/Matrix and then to /files/Matrix/SalesForce
I went through the logs and storeRevisionDescriptor was called for the following Uri's:
/ /users /users/[each and every user] /roles /roles/[each and every role] /Actions /Actions/[each and every Action] /files /history /workingResource
I verified that all of the xml files from root.def.xml to workingResource.def.xml had modified dates corresponding to my session and there were.
I am glad to hear the transient locks are not persisted, it was a
guess.
The above test appears to stop hitting and updating these files after the first pass, but in tracing my own code I have seen storeRevisionDescriptor being called on nodes not being modified in
any
way when other WebDAV methods are running.
So my conclusion is that there is a flaw, storeRevisionDescriptor is being called when nothing in the descriptor has changed or should
change
and that is a waste of cycles at best.
Michael Oliver CTO Matrix Intermedia Inc. 3325 N. Nellis Blvd, #1 Las Vegas, NV 89115 Phone:(702)643-7425 Fax:(520)844-1036
-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Saturday, July 17, 2004 1:43 PM
To: Slide Developers Mailing List
Subject: Re: Descriptor churn
Hi Michael,
which WebDAV methods are being executed when those storeRevisionDescriptor calls happen?
Most likely, it won't have anything with to do with transient locks as
they do not get persisted at all.
Oliver
Michael Oliver wrote:
Gents,
Reviewing slide logs as much as I do I am seeing a very high number
or
storeRevisionDescriptor calls when nothing has changed, the user is
just
navigating around. If this is resulting in filesystem I/O or
database
I/O then this seems to be a huge waste of cycles and should be
addressed
for scalability reasons. I am presuming this has to do with
transient
locks but I haven't had the time to research fully.
Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
