Client Cache¶
Every Cache<K,V> instance maintains an in-process near cache that contains deserialized versions of objects in the store. When reading objects, this client cache improves response times by reducing network utilization and deserialization overhead during object retrieval.
Overview¶
The client cache is a collection of references to deserialized objects that were recently accessed in the ScaleOut service. Effective use of the client cache is crucial to achieving the best possible performance, especially when accessing large objects. The coherency behavior and the size of the client cache can be adjusted to meet the needs of an application.
Coherency¶
By default, the client cache is strictly coherent: the Scaleout Client library always performs a version check with the ScaleOut service before returning an object to a caller. While this check requires a round-trip to the service, it is much faster than retrieving and deserializing the entire object. The contents of the deserialized cache will automatically be invalidated if the object is changed or removed by any of the servers in the farm, so the library will never return a stale version of a cached object.
If strict coherency is not needed, the frequency of version checks can be reduced so that they are only performed periodically.
Eviction¶
By default, the client cache is configured to store 10 MB (based on the number of bytes the object serializes too) of the applications most recently accessed objects. The client cache can be configured to evict objects when a defined threshold is hit. The eviction mechanism can be configured to use size-based LRU, and time-based eviction.
Usage Guidelines¶
Avoid Unpersisted Modifications¶
The client cache should not be used if an application needs to retrieve an object, modify it, and then discard those changes by not persisting them to the ScaleOut service. This usage pattern will cause the deserialized cache to get out of sync with the authoritative ScaleOut service.
If an application needs to modify a retrieved object outside of the normal read/update usage pattern, one of the following steps should be taken to avoid corrupting the client cache:
When building a Cache instance, disable the client cache.
Retrieve a deep copy of the object on a call-by-call basis. Deep copies can be freely modified without having to persist changes back to the service.
Optimistic Updates¶
The client cache should not be used when optimistic updates are performed. In the case of an update conflict, modifications to a retrieved object must be discarded, causing the client cache to get out of sync with the ScaleOut service. Always use deep copies when retrieving an object that will be optimistically updated.