John Blum created GEODE-6152:
--------------------------------
Summary: 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
Reporter: John Blum
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)
