Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Date: Thu, 5 Jul 2012 11:23:34 +0000 (UTC)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: oak-dev@jackrabbit.apache.org
Message-ID: <332683499.7916.1341487414651.JavaMail.jiratomcat@issues-vm>
In-Reply-To: <1329110594.34.1337865475698.JavaMail.jiratomcat@issues-vm>
Subject: [jira] [Commented] (OAK-114) MicroKernel API: specify retention
 policy for old revisions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406997#comment-13406997 ] 

Jukka Zitting commented on OAK-114:
-----------------------------------

bq. The javadoc is possibly not clear enough: a revision returned by getHeadRevision remains accessible for at least 10 minutes ...

Ah, you're right. That solves the problem above.

If we are keeping track of when a particular revision was last returned by {{getHeadRevision}}, wouldn't it be simple to use the same mechanism to also keep track of when revisions are returned from or passed to other {{MicroKernel}} methods? I don't see how that would imply any more "complex state management" than what's already needed.

The benefit of switching from "last returned as head revision" to "last accessed/seen" for figuring out when a revision is still needed is that we can allow unused revisions expire much faster. With the "last accessed/seen" pattern there'll be no problem with an expiry time of just a few seconds, which would in most cases allow the garbage collector to be much more aggressive than with the 10 minute time proposed here.

To illustrate the difference, consider a heavy write case where we have 100 commits per second hitting the repository. With a 10-minute expiry time the repository will have to keep track of something like 60k revisions, whereas with a shorter expiry time we can easily push that down to just a few hundred revisions.
                
> MicroKernel API: specify retention policy for old revisions
> -----------------------------------------------------------
>
>                 Key: OAK-114
>                 URL: https://issues.apache.org/jira/browse/OAK-114
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: mk
>            Reporter: Stefan Guggisberg
>            Assignee: Stefan Guggisberg
>         Attachments: OAK-114.patch
>
>
> the MicroKernel API javadoc should specify the minimal guaranteed retention period for old revisions. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira