You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Darrel Schneider (Jira)" <ji...@apache.org> on 2021/03/12 20:42:00 UTC

[jira] [Commented] (GEODE-9033) client read operations should not be blocked by a write operation

    [ https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300600#comment-17300600 ] 

Darrel Schneider commented on GEODE-9033:
-----------------------------------------

Another idea is to have the read do multiple reads if it detects that the version changed between reads of the version and value. It could eventually (after doing multiple reads) stop spinning and drop into synchronization. This would prevent a read from being blocked behind a blocked writer (since in that case the version and value are not changing) and also prevent a reader from spinning forever if the writers are constantly changing the version and value.

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