Cache Clients and Local Cache (Velocity)

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

In Microsoft project code named "Velocity," your application will use the DataCache object to store data in the cache. This object is referred to as the cache client. The cache client provides your application with a reference to a named cache in the cluster. It is created by using the DataCacheFactory object's GetCache method.

Note

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.

There are two types of cache clients: routing and simple. Each cache client also has the option to store cached data locally, which is named local cache. These cache client options are specified in the application configuration settings. For more information, see Application Configuration Settings (Velocity).

Security Considerations

Cache clients should be used only by applications residing on application servers in your datacenter, within the perimeter of the corporate firewall. Communications between cache servers and cache hosts is not encrypted and is vulnerable to malicious network "sniffing" and "replay" attacks.

We highly recommend that you secure the XML-based application configuration files used to specify the cache client. Data in the cache is not encrypted and is available to any cache client that has the appropriate configuration settings.

Note

End users of your cache-enabled application should not have direct network access to the cache servers.

Client Types

As seen in the following diagram, there are two types of cache clients used by cache-enabled application servers: routing and simple.

Routing Client

The routing client offers better performance than the simple client because it contains a routing table that is kept up to date by the lead hosts. The routing table is used to track cached object placement across all cache hosts in the cluster and identifies all cache hosts in the cluster. The routing client uses this table to optimize performance by making requests to the cache host where the object is physically located. For information about how to configure a routing client, see How to: Get Started with a Routing Client (XML) (Velocity) and How to: Get Started with a Routing Client (Code) (Velocity).

Note

In order to use a routing client, the computer that is running the cache-enabled client application must have network connectivity to all cache servers in the cluster.

Simple Client

Whenever possible, the routing client should always be used. Due to networking topologies, there may be cases where client applications can only access some of the cache servers in the cache cluster. In those cases, the simple client can be used to provide distributed cache resources.

To work in scenarios of limited cache server connectivity, the simple client has been designed to only require access to one cache host in the cluster. It has no routing capabilities and does not track where each cached object is stored. Because the simple client has no routing capabilities, requested cached objects often have to traverse additional cache hosts before reaching the simple client. This indirect path makes the simple client less efficient than the routing client.

For more information about how to configure a simple client, see How to: Get Started with a Simple Client (XML) (Velocity) and How to: Get Started with a Simple Client (Code) (Velocity).

Local Cache

Objects are serialized before they are stored on a cache host. Before simple and routing clients can use an object, it must first be de-serialized. In order to speed up this process of retrieving the object, enable local cache.

Local cache is available to both simple and routing clients. For more information about enabling local cache, see How to: Enable Local Cache (XML) (Velocity).

When local cache is enabled, a de-serialized copy of the object is saved in the memory of the computer that runs the cache-enabled application. Before retrieving cached objects from a cache host, the cache client first checks whether the object exists locally. If it does exist, the object is returned immediately to the application. If not, the object is fetched from the cache host and then stored locally in de-serialized form.

There are two types of invalidation for local cache: timeout-based invalidation and notification-based invalidation. For more information, see Expiration and Eviction (Velocity).

Object Consistency

Locally cached objects are stored within the same process space as the cache client process. Because methods of the DataCache object refer to those objects by reference, multi-threaded applications may experience inconsistent behavior when multiple threads use the same cached objects within the same process.

To avoid potential issues, threads from multi-threaded applications when using local cache should first make a copy of the object or take other measures to avoid concurrency issues between threads. Another approach is for each application thread to create its own cache client (DataCache object).

See Also

Concepts

General Concept Models (Velocity)
Concurrency Models (Velocity)
Expiration and Eviction (Velocity)
High Availability (Velocity)
Data Classification (Velocity)

Other Resources

Programming Guide (Velocity)
Administration Guide (Velocity)