[
https://issues.apache.org/jira/browse/OAK-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15009058#comment-15009058
]
Julian Reschke commented on OAK-3634:
-------------------------------------
Had a closer look, with somewhat surprising results.
1) The current behavior is easily understood as it's fully intentional: an
{{update()}} operation will apply the changes in memory and update the cache if
it contains exactly the document that the UpdateOp was applied to. This implies
that we'll put something into the cache without knowing its persisted state.
(Note that RDB and Mongo behave exactly the same way here because the caching
logic for RDB was copied from Mongo back then).
Fixing this is trivial (ignoring performance for now): just remove the logic
that attempts to update the cache and invalidate instead.
But, surprise:
2) We actually have a test case that *expects* the behavior that this issue is
about; {{MultiDocumentStoreTest.testInterleavedUpdate2()}} which consequently
starts failing once the DS implementation caches less aggressively.
> RDB/MongoDocumentStore may return stale documents
> -------------------------------------------------
>
> Key: OAK-3634
> URL: https://issues.apache.org/jira/browse/OAK-3634
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
> Affects Versions: 1.3.10
> Reporter: Julian Reschke
> Attachments: OAK-3634.diff
>
>
> It appears that the implementations of the {{update}} method sometimes
> populate the memory cache with documents that do not reflect any current or
> previous state in the persistence (that is, miss changes made by another
> node).
> (will attach test)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
