[
https://issues.apache.org/jira/browse/GEODE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-6032:
-----------------------------
Priority: Critical (was: Major)
> 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
> Priority: Critical
>
> 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)
