[ https://issues.apache.org/jira/browse/OAK-6227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16013818#comment-16013818 ]
Vikas Saurabh commented on OAK-6227: ------------------------------------ (comment specific for document-mk case) [~mreutegg] bq. Checkpoints created by the DocumentNodeStore already contain an implicit timestamp. The revision timestamp can be used for this purpose. Yes, we can probably do that - but that creates would mean that doc-mk revisions would be bound to be converted to a timestamp. I understand that it's right today - but would we want to make that a constraint for future? bq. The only problem I see is backward compatibility. The plan for OAK-2808 is "best effort basis" - so, if an old checkpoint exists without a property that can be translated to a timestamp then the oldest-safe-timestamp can be 0 (with potentially a WARN log??). Also, "created" is currently already being pushed by AsyncIndexUpdate. bq. What happens when an application already uses a property with this name? Hmm... maybe "oak:created" then? (although that breaks the second argument of "created" being pushed by AsyncIndexUpdate above) > There should be a way to retrieve oldest timestamp to keep from nodestores > -------------------------------------------------------------------------- > > Key: OAK-6227 > URL: https://issues.apache.org/jira/browse/OAK-6227 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: core > Reporter: Vikas Saurabh > Assignee: Vikas Saurabh > Labels: datastore, performance > Fix For: 1.8 > > > For implementing OAK-2808 (eager/unsafe blob garbage collection approach), we > need a way for nodestores to expost last safe timestamp such that blobs > deleted before that timestamp can be eagerly collected (uniqueness of blob > and that it won't be resurrected elsewhere is assumed to be guaranteed > elsewhere e.g. OakDirectory's blobs have randomly generated bytes as content). > What we want to ensure in this task is that the garbage collection shouldn't > collect stuff that could still be retrieved back - for example checkpoints. > [~chetanm] suggested that it might be an overkill to have this API in > NodeStore - but maybe, it's ok to expose it in NodeStore mbean (where the > impl specific mbeans known implementation detail of the nodestore to expose > such data). > The mbean just needs to expose the safe oldest timestamp (UTC epoch!?). > Another thing that is potentially done in repositories (albeit not really > supported afaik) is rolling back repository head state by say offline journal > edit. -- This message was sent by Atlassian JIRA (v6.3.15#6346)