[
https://issues.apache.org/jira/browse/OAK-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-3081.
-----------------------------------
Resolution: Fixed
Merged into 1.2 branch: http://svn.apache.org/r1689853 and 1.0 branch:
http://svn.apache.org/r1689860
> SplitOperations may undo committed changes
> ------------------------------------------
>
> Key: OAK-3081
> URL: https://issues.apache.org/jira/browse/OAK-3081
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, mongomk
> Affects Versions: 1.0.10, 1.1.6, 1.2
> Reporter: Marcel Reutegger
> Assignee: Marcel Reutegger
> Priority: Blocker
> Fix For: 1.2.3, 1.3.3, 1.0.17
>
>
> There is a race condition when SplitOperations identifies garbage on a
> document. The feature was introduced with OAK-2421.
> The issue occurs if the following sequence of operations happens on a
> document:
> - The document is updated with e.g. _deleted.rX-0-1 = false within
> Commit.applyToDocumentStore()
> - Commit.createOrUpdateNode() perform the update and calls
> checkSplitCandidate(). The document becomes a split candidate, because it is
> over the threshold of 8kB
> - At the same time a background update is running and starts to look at the
> split candidates.
> - The background update looks at the document and calls
> SplitOperations.collectLocalChanges(). At this point _deleted.rX-0-1 = false
> is not committed and doc.isCommitted(rev) returns false
> - The commit proceeds, updates the commit root and sets the new head revision
> - The background update now calls SplitOperations.isGarbage(rX-0-1) and the
> method will return true!
> - The background update then removes _deleted.rX-0-1 = false together with
> the _commitRoot entry
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
