[
https://issues.apache.org/jira/browse/OAK-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17926065#comment-17926065
]
Julian Reschke commented on OAK-10595:
--------------------------------------
trunk: (1.62.0)
[76a1f4b783|https://github.com/apache/jackrabbit-oak/commit/76a1f4b783c83dd2c26646055326999124347293]
[f8c61da771|https://github.com/apache/jackrabbit-oak/commit/f8c61da771b4668bdea388131b9588062a0f03ba]
> Cached data before a collision rollback can be read as committed
> ----------------------------------------------------------------
>
> Key: OAK-10595
> URL: https://issues.apache.org/jira/browse/OAK-10595
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Priority: Major
> Labels: candidate_oak_1_22
> Fix For: 1.62.0
>
>
> There is a race-condition between a collision rollback and
> MongoDocumentStore's nodesCache leaking uncommitted data, that later gets
> treated as if committed.
> Under normal circumstances, a collision is properly cleaned up via a rollback
> : all colliding data written is removed, and the revision was never marked as
> committed in the first place. Without the revision marked as committed,
> no-one would know of that revision - i.e. it wouldn't be able to be read
> since that clusterId doesn't update parent's lastRevs etc. Subsequent updates
> on involved documents result in caches to be updated accordingly, after which
> all traces from a collision rollback are gone.
> But if a peer cluster manages to read and cache uncommitted data, that later
> is rolled back due to a collision, it can happen that it treats that data as
> if committed.
> This situation only persists as long as that process is running - since this
> is dependent on cached data. The data in the physical repository is always
> consistent. So a restart will cause that uncommitted data to disappear again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
