[
https://issues.apache.org/jira/browse/OAK-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245733#comment-15245733
]
Marcel Reutegger commented on OAK-4112:
---------------------------------------
AFAIU the Guava BloomFilter implementation is not thread-safe. I think this
means concurrent put operations on the bloom filter may not be reflected
correctly and with the current (lack of) synchronization in
CacheChangesTracker.LazyBloomFilter there is no happens-before relationship
between a put() and a mightContain(). The volatile filter field only guarantees
that the first put is visible by a subsequent mightContain() of another thread.
> Replace the query exclusive lock with a cache tracker
> -----------------------------------------------------
>
> Key: OAK-4112
> URL: https://issues.apache.org/jira/browse/OAK-4112
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk, mongomk
> Reporter: Tomek Rękawek
> Labels: performance
> Fix For: 1.6
>
> Attachments: OAK-4112-1.patch, OAK-4112-2.patch, OAK-4112.patch
>
>
> The {{MongoDocumentStore#query()}} method uses an expensive
> {{TreeLock#acquireExclusive}} method, introduced in OAK-1897 to avoid caching
> outdated documents.
> It should be possible to avoid acquiring the exclusive lock, by tracking the
> cache changes that occurs during the Mongo find() operation. When the find()
> is done, we can update the cache with the received documents if they haven't
> been invalidated in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)