[jira] [Assigned] (OAK-10595) Cached data before a collision rollback can be read as committed

["Stefan Egli (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Egli reassigned OAK-10595:
---------------------------------

    Assignee: Stefan Egli

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