[
https://issues.apache.org/jira/browse/OAK-3287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172351#comment-15172351
]
Teodor Rosu commented on OAK-3287:
----------------------------------
I spent some time trying to the optimize the first proposal.
* pro. The advantage is that the repository always contains all reachable
revisions and commits.
* con. The major disadvantage ,as mentioned, is that is write intensive and I’m
not sure it can be tweaked to greatly reduce writes.
Regarding the second approach:
* pro. I agree. This should not affect write or cpu performance as much as 1).
* pro. IIUC this should free space quicker than 1) since it will not keep all
reachable revisions.
* con. The big disadvantage is that all old uncommited changes need to be
removed before the actual cleanup kicks in or the repository will be corrupt.
Some corner cases might exist : e.g. oak process killed during commit, no
cluster node has an older "border RevisionVector" etc..
> DocumentMK revision GC
> ----------------------
>
> Key: OAK-3287
> URL: https://issues.apache.org/jira/browse/OAK-3287
> Project: Jackrabbit Oak
> Issue Type: Epic
> Components: documentmk, mongomk, rdbmk
> Reporter: Michael Marth
> Assignee: Marcel Reutegger
> Fix For: 1.6
>
>
> Collector for various tasks on implementing DocMK revision GC
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
