[ 
https://issues.apache.org/jira/browse/JCR-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694137#action_12694137
 ] 

Michael Dürig commented on JCR-2050:
------------------------------------

Above patch factors item invalidation into a InvalidationStrategy. There are 
two separate implementations: EagerInvalidation and LazyInvalidation. 
EagerInvalidation behaves like refreshing used to behave. LazyInvalidation 
implements above proposal. 

> Optimize refresh operations 
> ----------------------------
>
>                 Key: JCR-2050
>                 URL: https://issues.apache.org/jira/browse/JCR-2050
>             Project: Jackrabbit Content Repository
>          Issue Type: Improvement
>          Components: jackrabbit-jcr-benchmark, jackrabbit-jcr2spi
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>            Priority: Minor
>         Attachments: JCR-2050.patch
>
>
> With the current implementation (recursive) refresh operations cause a full 
> traversal of the sub-tree rooted at the item causing the refresh. This is 
> potentially expensive. 
> Instead of invalidating each item in the respective sub-tree I propose to 
> mark the root of the sub-tree as invalidated. Such a mark would include a 
> time stamp. Also individual items would be time stamped with their resolution 
> time. When an item is accessed, it would check if its resolution time stamp 
> is older than the latest invalidation time stamp. If so, it checks whether 
> the invalidation applies to it at all (by traversing up the path) and if so 
> it would re-resolve itself. In any case its resolution time stamp will be 
> updated.
> This approach would make invalidation much cheaper without putting much 
> additional load to simple item access. Moreover most of the additional load 
> (traversing up the path) only applies when an invalidation is pending.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to