[
https://issues.apache.org/jira/browse/GEODE-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320297#comment-17320297
]
Darrel Schneider commented on GEODE-9033:
-----------------------------------------
The only solution I can think of for this is, as Mark wrote, to sync on another
object while setting the version and value fields. So writers would still sync
on the region entry for the entire op, but would only do the new sync while
writing the version and value fields.
The client read code would only do the version value sync, not the region entry
sync.
A problem with this is that while the client is reading the value it may find
that it is on disk. In that case the client faults it in from disk and writes
the value field. To do this safely it needs to sync on the region entry. So in
this case the reader thread will sync on VersionValueSync and then
RegionEntrySync. But the write threads sync on RegionEntrySync first and
VersionValueSync second. This change in lock ordering will cause a thread
deadlock. So we will need to figure out how to solve this client read fault in
dead lock before making this change.
> 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)
