Table of Contents

Every Cache 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 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 the 1000 most recently accessed objects. The cache can be configured to perform eviction on an LRU or random basis. The capacity of the cache can be either a simple object count or a memory limit. Custom client cache implementations can also be used to meet specific requirements. See Eviction for more information on configuring the client cache.

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:

  1. When building a Cache instance, disable the client cache.
  2. 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.