[
https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17308909#comment-17308909
]
Darrel Schneider commented on GEODE-9033:
-----------------------------------------
I don't think atomics are a good solution here because the version stamp info
is actually stored in 6 non-volatile fields on the RegionEntry instance. I
think to use atomics we would need to change how the info is stored in the
RegionEntry and that may lead to a higher memory overhead.
As I have thought more about this solution it seems pretty basic. We just need
to make sure that code that sets both the version stamp and value does the
version stamp set first. We could limit how many spins we do before dropping
out of the spin loop and getting the sync. This would prevent clients from
spinning forever on entries that are being update frequently.
> 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
> Priority: Major
>
> 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)
