Over a million developers have joined DZone.

Windows Server AppFabric Cache Programming

DZone's Guide to

Windows Server AppFabric Cache Programming

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

Named Cache

The named cache in AppFabric cache through AppFabric Cache Administration console, using the following Powershell command:

New-Cache myCache

New-Cache myCache -ReadThroughEnabled true -ProviderType "CustomCacheProvider, Version=, Culture=neutral, PublicKeyToken=b3fae62df3e2d49e" -ProviderSettings @{"CacheName"="myCache";} –TimeToLive 1440

Regions in Cache

Each named Cache can contain one or more named regions. Regions are an additional data container used to isolate and hold data in the cache. All items in each region stored together Default region created for each Cache if none explicitly created. You must create a region programmatically before trying to store an item inside them. Once you start using Regions you must always reference the region by their names.

var dcf = new DataCacheFactory();

//get the cache named "myCache"

var cache = dcf.GetCache("myCache");

//Add a region named "region1" - returns false //if already exists

var ret = cache.CreateRegion("region1", false);

Usage patterns

The AppFabric cache maintains its data in physical memory. It is not guaranteed that these data remain forever in cache and hence cannot assume that cache client's to run smoothly. There may be a case where, we would come across the whole cache cluster going down. In these situations, the cache client should be armed with intelligent mechanisms to make calls to external data storage respository and continue to support application availability.

There are multiple ways and strategies available to handle such kind of scenarios. We have 1) Cache-aside programming model and 2) Read-through / write-behind programming model. In the Cache-aside programming model, it is the responsibility of the cache-client to explicitly make calls to SQL Server (external storage repository) to fetch results, store them inside cache and consume. In this case, additional SQL connection is made to query and handle data un-availability in cache. In the Read-through / write-behind programming model, we create custom cache provider assembly, that makes explicit calls to SQL Server database and stores items in cache when one is un-available during request. In this case, the cache client is reduced with burden of making extra calls to database. Plus, when items are written to a cache, the written items are periodically and asynchronously written to the backend.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}