Exceptions and Limitations

In some application scenarios, delta propagation does not show any significant performance benefits. On occasion it results in degradation. There are other limitations and exceptions related to delta propagation.

Errors in Delta Propagation

Errors in delta propagation fall into two categories based on how they are handled:

  • Problems applying the delta that can be remedied if the originating member sends the full value in place of the delta. Your put operation does not see errors or exceptions related to the failed delta propagation. The system automatically does a full value distribution to the receiver where the problem occurs. This type of error includes:

    • Unavailable entry value in the receiving cache, either because the entry is missing or its value is null. In both cases, there is nothing to apply the delta to and the full value must be sent. This is most likely to occur if you destroy or invalidate your entries locally, either through application calls or through configured actions like eviction or entry expiration.
    • InvalidDeltaException thrown by fromDelta method, programmed by you. This exception enables you to avoid applying deltas that would violate data consistency checks or other application requirements. Throwing this exception causes a send of the full value.
    • Any error applying the delta in a client in server-to-client propagation. The client retrieves the full value from the server.
  • Problems creating or distributing the delta that cannot be fixed by distributing the full value. These problems are caused by errors or exceptions in hasDelta or toDelta. In these cases, your put operation fails with an exception.

Performance Limitations

Consider the following situations in which delta propagation adversely affects performance:

  • Added costs of deserializing your objects to apply deltas. Applying a delta requires the entry value to be deserialized. Once this is done, the object is stored back in the cache in deserialized form. This aspect of delta propagation only negatively impacts your system if your objects are not already being deserialized for other reasons, such as for indexing and querying or for listener operations. Once stored in deserialized form, there are reserialization costs for operations that send the object outside of the member, like values sent in response to netSearch or client requests, and storage to disk. The more operations that require reserialization, the higher the overhead of deserializing the object.
  • Cloning. Cloning can affect performance. Not using cloning is risky, however, as you are modifying cached values in place. Make sure you synchronize your entry access to keep your cache from becoming inconsistent.
  • Problems applying the delta that cause the system to go back to the originator for the full entry value. In this scenario, the overall operation costs more than sending the full entry value in the first place. The problem can be exacerbated if your delta is sent to a number of recipients, all or most of them request a full value, and the full value send requires the object to be serialized.
  • Disk I/O costs associated with overflow regions. If you use eviction with overflow to disk, on-disk values must be brought into memory in order to apply the delta. This is much more costly than removing the reference to the disk copy, as you would do with a full value distribution into the cache.

Configurations That Require Full Values

Clients can always send deltas to the servers, and servers can usually sent deltas to clients. The following configurations require the servers to send full values to the clients, instead of deltas:

  • When the client’s geode.properties setting conflate-events is set to true, the servers send full values for all regions.
  • When the server region attribute enable-subscription-conflation is set to true and the client geode.properties setting conflate-events is set to server, the servers send full values for the region.
  • Servers send full values to client regions that are configured to not cache data—with the PROXY RegionShortcut in their region attributes refid.

To use the delta propagation feature, all updates on a key in a region must have value types that implement the Delta interface. You cannot mix object types for an entry key where some of the types implement delta and some do not. This is because, when a type implementing the delta interface is received for an update, the existing value for the key is cast to a Delta type to apply the received delta.

General Limitations

Sometimes fromDelta cannot be invoked because there is no object to apply the delta to in the receiving cache. When this happens, the system sends the full value. There are two possible scenarios:

  • If the system can determine beforehand that the receiver does not have a local copy, it sends the initial message with the full value. This is possible when regions are configured with no local data storage, as when you are using them to provide data update information to listeners.
  • In less obvious cases, as when an entry has been locally deleted, first the delta is sent, then the receiver requests a full value and that is sent. Whenever the full value is received, any further distributions to the receiver’s peers or clients uses the full value.

No deltas are propagated for:

  • Transactional commit on the server
  • The putAll operation