John Blum created GEODE-6032:
--------------------------------
Summary: Entire object is serialized again (and again) when
Delta.hasDelta returns false and client is using PROXY Region
Key: GEODE-6032
URL: https://issues.apache.org/jira/browse/GEODE-6032
Project: Geode
Issue Type: Bug
Components: client/server
Reporter: John Blum
Currently, if a cache client application is configured with a client {{PROXY}}
Region, and the application is also using {{DataSerialization}} to de/serialize
objects to/from the servers, and the application domain objects implement the
{{org.apache.geode.Delta}} interface then Apache Geode will incorrectly send
the entire object (again) when {{Delta.hasDelta}} returns *false*.
It is understandable that the application domain object needs to be serialized
in its entirety the first time the object is sent to the server(s) (or if the
object is later, subsequently removed or has expired/been evicted, and then
needs to be re-added for whatever reason).
However, once the server(s) know about the object, then only ever a "delta"
should be sent, and only when {{Delta.hasDelta()}} returns *true*. Otherwise,
if {{Delta.hasDelta()}} returns *false*, then most certainly, the entire object
should not be sent again, otherwise it is possible for the application to enter
a race condition scenario where the object gets "overwritten", and as a
results, the application can lose data (aka "_lost updates_").
If users were to change their client Region data management policy from
{{PROXY}} to {{CACHING_PROXY}} then this works as expected. Apache Geode will
only send for and object it already knows about if there is actually a "delta",
otherwise Geode does nothing (that is, does not send the object, or rather any
delta to the servers since there is technically nothing to send).
Obviously, in the {{CACHING_PROXY}} case, there is "local" state to compare
against, and therefore, Geode knows about the object already, in that it
"exists". It can therefore assess the object to determine if it is the
same/unchanged, and not do anything in the case the {{Delta.hasDelta}} returns
*false*, thus the "application" informing Geode there is nothing to send.
Clearly, in the {{PROXY}} case, this "local" state does not exist, and
therefore, Geode does not know whether the object (already) exists on the
servers or not. So, if {{Delta.hasDelta()}} returns *false*, it is unsure
whether the objects exists or not and so decides just to send the entire object
again, a "_premature optimization_" to be sure, which now has sacrificed
"_correctness_", and has amplified the possible "_race conditions_" on the
application side.
However, this is no different than if {{Delta.hasDelta()}} returns *true* and
the object is *not yet* known by the servers. When the client sends just the
delta in this case, the server will send back to the client, I don't know
anything about this object for which the delta needs to be applied, and
therefore, the client must turn around and send it the object anyway.
So, in the {{PROXY}} case, it would be better if the client made a
determination about whether the object truly exists on the server side or not
before arbitrarily and falsely assuming the entire object should be sent again
if the {{Delta.hasDelta()}} returns *false*. The client simply does not know
and should "verify" before sending the object.
Obviously this affects performance, but is a small price to pay (and the
"correct" thing to do) compared with "_lost updates_" and amplifying "_race
conditions_", client-side.
There is also a situation where {{CACHING_PROXY}} client Regions can even
*fail*, and that is when {{copy-on-read}} is set to *true*.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
