Cache

When creating new applications or functionality on top of the Verint Community platform, you'll need to consider caching for performance. Rather than using the ASP.net caching object, utilize the Verint Community caching framework so that runtime adjustments can be made without compilation, and you have finer control over where you are caching your items. The Telligent.Evolution.Extensibility.Caching namespace provides an API for adding caching abilities to a Verint Community component.

When to use the Verint Community Caching Framework

When you need to create your own custom application and you need finer control over where you are caching your items than is offered by ASP.net caching.

Cache keys and tags

All items in the cache will have an associated key that can be used to identify it. Keys are not case-sensitive and will always be stored in their lowered-case form.

In addition to a key, you can further identify an item by placing one or more tags on it. Like keys, tags are not case-sensitive and will be stored in their lowered-cased form.

Tags are useful when grouping data into logical partitions. Using tags, you can expire a group of items in the same logical partition without knowing all the individual keys. While tags are powerful in this regard, they should never be used in substitution of a good key generating algorithm. Tag operations are very slow in comparison to single key lookups and removals, so be very selective about how and when you use them.

Choosing a cache scope

All cache operations require one or more CacheScope values. When defining a cache layer, each layer will identify what kind of cache it is by using a cache scope.

For example, the built-in ASP.NET cache identifies itself as a Process scope layer because it stores items in locations that are available to all threads running inside the application.

Before caching an item, you'll need to decide what scope(s) to operate in. Here are some general guidelines that you may follow:

Cache Timeouts

When items are placed into cache, it is not necessary to give a timeout. In these cases, the currently configured default timeout value is used. The out-of-the-box default timeout is 1 minute and 40 seconds.

Many objects in Verint Community use the default timeout value. In addition to a very simple scaling mechanism, controlling the default timeout allows for finer control over the cache system in webfarm scenarios where staleness is a concern. Generally, if more than one server is running a site, the default timeout value should be low to keep staleness at a minimum. The lower the value, the less likely you are to see staleness - but at the cost of decreased cache performance.

Samples

All of the following examples assume we have this defined (which requires a reference to Telligent.Evolution.Components.dll):

using Telligent.Evolution.Extensibility.Caching.Version1;

Retrieving an item from cache.

var obj = CacheService.Get("key", CacheScope.Context | CacheScope.Process);

Putting an object into cache.

// Get the object from the source.
var obj = GetObjectFromDataSource();

CacheService.Put("key", obj, CacheScope.Context | CacheScope.Process, TimeSpan.FromMinutes(1));

Putting an object into cache using the default timeout.

// Get the object from the source.
var obj = GetObjectFromDataSource();

CacheService.Put("key", obj, CacheScope.Context | CacheScope.Process);

Putting an object into cache using the default timeout and cache tags.

// Get the object from the source.
var obj = GetObjectFromDataSource();

CacheService.Put("key", obj, CacheScope.Context | CacheScope.Process, new string[] { "tag1" });

Removing an item from cache.

CacheService.Remove("key", CacheScope.Context | CacheScope.Process);

RemoveByTags to remove a group of tagged items from cache.

CacheService.RemoveByTags(new string[] { "tag1" }, CacheScope.Context | CacheScope.Process);