Cache Clients and Local Cache (Windows Server AppFabric Caching)
When using the caching features of Windows Server AppFabric, your application will use the DataCache object to store data in the cache. This object is referred to as the cache client. To create a cache client that uses the default cache, use the GetDefaultCache method. To create a cache client that uses a named cache, use the GetCache method.
For performance reasons, we recommend that you minimize the number of DataCacheFactory objects created by your cache-enabled application. Store the DataCacheFactory object in a variable available to all parts of the application that use cache clients.
We highly recommend that you secure any XML-based application configuration files used to specify the cache client. The machine names of cache hosts are specified in this file. However, for another client to actually access the cache cluster, they would require permissions to access the cache cluster.
The server stores objects in serialized form in the cache. When a cache client requests an object from the cache, the server sends it to the client over the network. The cache client then deserializes the object for use by the client application. To speed up the process of retrieving an object, enable local cache. For more information about enabling local cache, see Enable Windows Server AppFabric Local Cache or Enable Windows Server AppFabric Local Cache (XML).
When local cache is enabled, the cache client stores a reference to the object locally. This keeps the object active in the memory of the client application. When the application requests the object, the cache client first checks whether the object resides in the local cache. If so, the reference to the object is returned immediately without contacting the server. If it does not exist, the object is retrieved from the server. The cache client then deserializes the object and stores the reference to this newly retrieved object in the local cache. The client application uses this same object.
The lifetime of an object in the local cache is dependent on several factors, such as the maximum number of objects in the local cache and the invalidation policy. There are two types of invalidation for local cache: time-out-based invalidation and notification-based invalidation. For more information, see Expiration and Eviction (Windows Server AppFabric Caching).
After objects are stored in the local cache, your application continues to use those objects until they are invalidated, regardless of whether those objects are updated by another client on the cache cluster. For this reason, it is best to use local cache for data that changes infrequently.
Locally cached objects are stored within the same process space as the cache client process. When a cache client requests a locally cached object, the client receives a reference to the locally cached object rather than a copy. This is an important consideration for multithreaded applications that may be modifying the same locally cached object from multiple threads. These applications can employ standard .NET Framework coding techniques for synchronizing changes to objects from multiple threads. It is also possible to create separate DataCacheFactory objects for each thread. However, this should be done judiciously as the overhead for creating many cache factories can reduce the benefits.
Windows Server AppFabric Caching Physical Architecture Diagram
Windows Server AppFabric Caching Logical Architecture Diagram
Expiration and Eviction (Windows Server AppFabric Caching)
Enable Windows Server AppFabric Local Cache
Enable Windows Server AppFabric Local Cache (XML)
Developing a Cache Client (Windows Server AppFabric Caching)