[
https://issues.apache.org/jira/browse/JCR-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069132#comment-13069132
]
Julian Reschke commented on JCR-3004:
-------------------------------------
I would recommend to drop support for the Label header.
See <http://www.webdav.org/deltav/protocol/rfc3253-issues-list.htm>:
8.3_ LABEL_HEADER
...
The Label header has poorly defined semantics when used with Depth header, and
is inconsistent with HTTP variant processing.
...
Replace the Label header with a DAV:labeled-version report.
and draft in
<http://www.webdav.org/deltav/protocol/draft-ietf-webdav-versioning-xx.7.htm>
> Check if a DAV-Request has a Label in the header, before checking if it's
> version-controlled
> --------------------------------------------------------------------------------------------
>
> Key: JCR-3004
> URL: https://issues.apache.org/jira/browse/JCR-3004
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-jcr-server
> Affects Versions: 2.2.7, 2.3.0
> Reporter: Christian Stocker
> Assignee: angela
> Fix For: 2.3.0
>
> Attachments: patch_commit_85c91801358a.patch
>
>
> When looking at our MySQL logs, I realized that jackrabbit on each DAV
> Request calls the VERSION table every time I get a new node (which is not
> cached yet), even if I only do a simple getNode.
> As a versioning table can get pretty large, this may have a performance
> impact.
> I found out, that DavResourceFactoryImpl checks, if a node is versioned to
> decide, if we have to check for the Label header to later check out another
> version for the GET request. I re-ordered those checks now so that it first
> checks, if there's an http Label-header and only then checks, if the node is
> versioned. The check for a Label header should be much faster than checking a
> DB, if it's versioned (and scale much better, too)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
