[
https://issues.apache.org/jira/browse/GEODE-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6152:
-----------------------------
External issue URL: https://jira-pivotal.atlassian.net/browse/GEM-2277
Labels: Proxy Region client (was: )
> 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
> Labels: Proxy, Region, client
>
> 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)
