Migrating from Windows Server AppFabric Caching to ScaleOut StateServer®
Migrating a Cache Client

ScaleOut client applications can subscribe to the NamedCache.ObjectExpired event to receive notifications when objects are about to be automatically removed from the distributed data grid. The expiration event will be fired for one of three reasons:

The reason for the event expiration is available in the NamedCacheObjExpiredEventArgs instance that is provided to your event handler. This event argument contains other useful properties such as the key of the object and gives you the option to cancel the expiration so that the object remains in the store.

In the following example, an expiration event handler is registered with a named cache, which uses the provided event arguments to print out the reason for an object’s removal:

using System;
using System.Threading;
using Soss.Client;

class Program
{
  static void Main(string[] args)
  {
    NamedCache cache = CacheFactory.GetCache("Sample Cache");
    cache.ObjectExpired += cache_ObjectExpired;

    // Insert an object with a 5-second timeout:
    CreatePolicy policy = new CreatePolicy();
    policy.Timeout = TimeSpan.FromSeconds(5);
    cache.Insert("key1", "value", policy, true, false);

    // Wait for the expiration so we can see the event fire:
    Thread.Sleep(7000);
  }

  static void cache_ObjectExpired(object sender,
                                  NamedCacheObjExpiredEventArgs eventArgs)
  {
    Console.Write("'{0}' is expiring: ", eventArgs.Key.GetKeyString());
    switch (eventArgs.NamedCacheEventCode)
    {
      case NamedCacheEventCode.ObjectTimeout:
        Console.WriteLine("Object timed out.");
        break;
      case NamedCacheEventCode.LowMemory:
        Console.WriteLine("Object evicted due to low mem.");
        break;
      case NamedCacheEventCode.Dependency:
        Console.WriteLine("Object removed due to dependency relationship.");
        break;
    }
  }

}

// OUTPUT:
// 'key1' is expiring: Object timed out.

Expiration events are load balanced among instances of your client application, so only one client will be notified of each expiration. The SOSS service pushes events to clients rather than requiring clients to poll for them, and the service will retry delivery if a client application is temporarily unavailable. This results in a strong guarantee of event delivery and a more scalable, reliable event distribution model.

Expirations events are enabled by default in the SOSS service. By default, the service will try to deliver an event to your application one time for each expiring object—the number of retries can be increased by modifying the max_event_tries parameter in the service’s soss_params.txt file. If the value is greater than 1 then the service will attempt to retry the delivery of an event once per minute. Event delivery can be completely disabled by setting the max_event_tries parameter to 0.