[
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)
