Microsoft has finally released Community Technology Preview 3 of their "distributed in-memory application cache platform for developing scalable, high-performance applications." And, as a caching guy who will be speaking about Velocity in Vegas in a few short weeks, I've been waiting for the release, which I played with this past weekend. First things first, though. I use memcached at work, a blazingly fast, in-memory, distributed cache. One of the key differences between memcached and Velocity is that Velocity is a "cache platform," a phrase which brings to mind unwieldy to begin with. Then, during the install, we see this dialog:

The DistributedCacheService makes sense, but why the RemoteAdministration and File and Printer Sharing? Well, because it's a platform and not a simple cache. And it stores all of the configuration shared between the servers in either a SQL database or a shared SQL database. See, if you choose a SQL database, then it stores it in a database handled by SQL Server. If, on the other hand, you choose network share, well, then you need to have a network share set up and configure it as seen in this screen:

And in that directory you'll find two SQL Server Compact Edition Database files, all of which I'll leave for another day to explore.

So, let's look at some of the things that they said would be in CTP3:

• Bulk Access APIs
• Read through/Write behind
• Security
• Cache Event Notifications

Two out of four ain't bad, especially given the complexities of the two pieces left, so let's take a quick look at API changes and then look at those two pieces in depth.

API Changes

For the most part, API Changes were simple and had more to do with consistency than anything else. The namespace was changed from System.Data.Caching to Microsoft.Data.Caching. I suspect this was done, in part, to set it up for the Read through/Write behind where it will be writing using the Microsoft.Data namespace. In line with those changes, all of the classes, enumerations and delegates were changed to have Data in front of them (Cache became DataCache, CacheException became DataCacheException, etc). All in all, it was fairly easy to replace the DLLs from CTP2 with the ones from CTP3, do a global search and replace from using System.Data.Caching; to using Microsoft.Data.Caching; and finally compile to find all of the places where I needed to add Data in front of classes.

The hardest part was some minor rearranging of parameters within overloaded function calls. Oh, and Tags. Tags have been changed a bit and I'll have to post on them separately. Don't know if it was a good change or a bad one, yet, just know it was a change.

Security

Security changes in Velocity are actually related to what level the caching service runs under, specifically Network Service. And, while you still need to be an administrator to install it, the installation program handles some of the permission settings that had to be handled manually in CTP2. Also, they've added a disclaimer:

Although these efforts help to secure the cache cluster; they are not enough to protect it from malicious activity. "Velocity" is designed to be operated in the datacenter, within the perimeter of the corporate firewall. Data transfer is not encrypted and is at risk of network "sniffing" and "replay" attacks.

Cache Event Notifications

This was the big one that everyone was waiting for. One option in Velocity is to use a local cache for items. The advantage of using the local cache is that it keeps a copy of the deserialized object so you don't need to deserialize it from cache every time. In CTP2 you could store an item using local cache and it would store it in the full cache so everyone could use it but you wouldn't know that anything had happened to it until your Time To Live (TTL) had expired locally. To understand how this affected items, let's look at a quick example.

You cache an item with a 5 minute expiration. Your local cache TTL is set for 30 seconds. That means that you won't ask for the item from the real cache for 30 seconds. At 31 seconds, your application doesn't find it in the local cache and requests it from the full cache. The advantage is you have 30 seconds where you don't need to deserialize the object. The disadvantage is that someone could change the object a second after you get it and then you won't know about it until your 30 seconds are up. Which is where notifications comes in.

With Notifications, you basically configure your local cache to not have a TTL. When you get something to the cache that will expire in 5 minutes, it gets stored in your local cache set to expire at the same time the object in the real cache will expire. If someone removes the item or updates the item in the cache server, you'll get notified about it and invalidate your local cache so you get the server cache version next time. Which sounds nifty, except it's still a poll option, which is really the only way to be able to have this scale in any fashion. To understand this better, let's take a look at the architecture of Velocity as it applies to High Availability:

The cache cluster actually has defined Lead Hosts that manage the replication of data throughout the cache. Your Velocity client, when it has local caching with Notification turned on, basically queries these Lead Hosts to determine what's been changed. If every client who was needed to be notified of changes to the local cache registered a notification hook to the Lead Host so that the lead host actively notified a listener in the client when an item had changed it would quickly lose any scalability. Instead, your client polls the lead host every so many seconds to get a list of what has changed. Unfortunately, this is a finite list and, well, let's see what MS has to say:

Cache hosts can hold only a certain amount of cache operations in memory. It is possible, depending on system load, that some cache clients may not receive notifications before they are truncated in the cache host queues. Cache clients may also miss notifications when data is lost due to a cache server failure while the rest of the cluster remains running. In these cases, your cache client can discover that it has missed some cache notifications by using a failure notification.

I'll have more to say as I dig deeper into the Velocity demos but I have work to do now.