[
https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320292#comment-17320292
]
Darrel Schneider commented on GEODE-9033:
-----------------------------------------
The problem we are trying to solve is to read both the version stamp fields and
the version field atomically. They are always written while synchronized on the
region entry. But that sync is held for a long time (on a PR during
distribution, held during write to disk, held during the subscription queue
add) which can cause client reads to take a long time.
One possible solution was to do a spin read until the reader observes that the
version stamp did not change. But it turns out that could cause the reader to
associate the wrong version with a value. For example:
# T1 writes version 1
# T1 writes value 1
# T2 writes version 2
# T3 reads value 1
# T3 reads version 2 (even though T2 has not written value 2, it is possible
for it to read the non-volatile version 2).
# T3 reads spin value 1
# T3 spin reads version 2
# T3 sees the version has not changed so it associates value 1 with version 2
(this is wrong).
# T2 writes value 2
> client read operations should not be blocked by a write operation
> -----------------------------------------------------------------
>
> Key: GEODE-9033
> URL: https://issues.apache.org/jira/browse/GEODE-9033
> Project: Geode
> Issue Type: Improvement
> Components: client/server
> Affects Versions: 1.1.0
> Reporter: Darrel Schneider
> Assignee: Mark Hanson
> Priority: Major
> Labels: GeodeOperationAPI, performance
>
> Client read operations currently will be blocked by a write operation that is
> in progress.
> This is caused by the write operation holding a synchronization on the
> RegionEntry and LocalRegion.getDeserializedValue synchronizing the
> RegionEntry with clientEvent is not null in order to atomically obtain both
> the entry's value and version.
> The read code in LocalRegion that causes this is:
> {code:java}
> synchronized (regionEntry) {
> // value & version must be obtained atomically
>
> clientEvent.setVersionTag(regionEntry.getVersionStamp().asVersionTag());
> value = getDeserialized(regionEntry, updateStats,
> disableCopyOnRead,
> preferCachedDeserializable, retainResult);
> }
> {code}
> To fix this it may be possible to change the write operations to synchronize
> on something else while changing both the value and version (but not while
> doing anything else). Then the read code can sync on that new Object and not
> the RegionEntry instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
