[
https://issues.apache.org/jira/browse/GEODE-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16710918#comment-16710918
]
John Blum commented on GEODE-6152:
----------------------------------
The only known, current workaround for this situation is to set the cache's
{{copy-on-read}} configuration attribute to *true*. With {{copy-on-read}} set
to *true*, Geode is supposed to return a new object/copy for the Region entry
value mapped to the requested key on {{Region.get(key)}}.
Therefore, while {{copy-on-read}} should not be required in the case of a
client {{PROXY}} Region since there is supposed to be no "local state", due to
this bug it is required, and given the severity of the condition, it is highly
recommended.
This will have an impact on the client JVM since more objects will be created
for every request.
> Client PROXY Regions may return the same Object instance on get(key) and
> cause Thread-safety issues.
> ----------------------------------------------------------------------------------------------------
>
> Key: GEODE-6152
> URL: https://issues.apache.org/jira/browse/GEODE-6152
> Project: Geode
> Issue Type: Bug
> Components: client/server, regions
> Affects Versions: 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, 1.7.0
> Reporter: John Blum
> Priority: Critical
>
> According to Apache Geode's documentation (e.g.
> [Javadoc|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientRegionShortcut.html#PROXY]),
> client PROXY Regions are expected to return a new Object for each value on
> each {{Region.get(key)}} invocation.
> The documentation states:
> {quote}
> A PROXY region has no local state and forwards all operations to a server.
> {quote}
> Given the client cache (i.e. Region) contains "no local state" and "all
> operations are forwarded to a server", then this implies that the object, the
> Region's value mapped to the key, is serialized when sent to a server and
> deserialized when received from a server. The act of de/serialization
> constitutes a new object every, single, time.
> However, in a highly concurrent application (e.g. a Web application), with
> multiple Threads in the application potentially making concurrent data
> requests for the same "logical" domain object stored in Apache Geode, it is
> possible for the same object reference to be returned, even for a client
> {{PROXY}} Region.
> This is to be expected when using a {{CACHING_PROXY}}, since the client then
> has "local state", but for a client {{PROXY}} Region, there is, or should be
> no "local state".
> It turns out that internally, Geode applies an optimization wherein, if 2 or
> more Threads are concurrently making a data request for the same "logical"
> object, then only 1 Thread is allowed to proceed with the request while the
> other Threads will wait for the response that the permitted, requesting
> Thread received, thereby sharing the same object reference.
> This poses grave danger (race conditions due to lost updates, or incorrect
> decisions made due to stale state) if the non-unique object type is not
> Thread-safe. Under other conditions/configurations (e.g. when sending
> {{Deltas}}), it is even possible to "lose data" due to competing and
> conflicting data access operations, which results in a "_last-one-wins_"
> scenario.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
