Delta Propagation Properties
Delta Propagation Properties
This topic describes the properties that can be used to configure delta propagation.
Delta propagation properties can be configured through the API and through the gemfire.properties and cache.xml files.
A gemfire.properties boolean that enables or disables delta propagation. When false, full entry values are sent for every update. The default setting is true, which enables delta propagation.
Properties props = new Properties(); props.setProperty("delta-propagation", false); this.cache = new ClientCacheFactory(props).create();
A region attributes boolean that affects how fromDelta applies deltas to the local cache. When true, the updates are applied to a clone of the value and then the clone is saved to the cache. When false, the value is modified in place in the cache. The default value is false.
- If the Cache attribute copy-on-read is true, cloning is enabled, regardless of what this attribute is set to.
- Servers running continuous queries (CQs) always clone the existing value and apply the received delta on it, in order to have old and new values for the CQ event. Servers not running CQs use this attribute.
Cloning can be expensive, but it ensures that the new object is fully initialized with the delta before any application code sees it.
When cloning is enabled, by default GemFire does a deep copy of the object, using serialization. You may be able to improve performance by implementing java.lang.Cloneable and then implementing the clone method, making a deep copy of anything to which a delta may be applied. The goal is to reduce significantly the overhead of copying the object while still retaining the isolation needed for your deltas.
- It is possible for application code to read the entry value as it is being modified, possibly seeing the value in an intermediate, inconsistent state, with just part of the delta applied. You may choose to resolve this issue by having your application code synchronize on reads and writes.
- GemFire loses any reference to the old value because the old value is transformed in place into the new value. Because of this, your CacheListener sees the same new value returned for EntryEvent.getOldValue and EntryEvent.getNewValue .
- Exceptions thrown from fromDelta may leave your cache in an inconsistent state. Without cloning, any interruption of the delta application could leave you with some of the fields in your cached object changed and others unchanged. If you do not use cloning, keep this in mind when you program your error handling in your fromDelta implementation.
- The fromDelta method generates more garbage in memory.
- Performance is reduced.
<region name="region_with_cloning"> <region-attributes refid="REPLICATE" cloning-enabled="true"> </region-attributes> </region>
RegionFactory rf = cache.createRegionFactory(REPLICATE); rf.setCloningEnabled(true); custRegion = rf.create("customer");
gfsh>create region --name="region_with_cloning" --type=REPLICATE --enable-cloning=true