Velocity CTP: can we 'search' for objects?

Question

Phil, I appreciate your answers very much.

As regards my questions concerning regions, I am trying to grasp the functionality of the API, not actually the architecture or infrastructure of the service/application/platform.

So I am trying to determine what the limitations are as regards the ability to return objects when the precise key is not known or when it is desired that more than one object with related or similar keys should be returned.

When I examine the API, I don't see any 'query language' and the only commands that seem to approach the functionality I describe above are associated with 'regions'.

From the lingo surrounding the description of how regions are implemented in the platform, I deduced (correctly or incorrectly?) that when a region was defined (created?) it would be deployed on only a single cache server among the several cache servers in a multi-server implementation of AppFabric.

That is, it appeared to me that what was being described was that a 'namespace' [region] in AppFabric was fundamental to whatever 'indexing' capability the AppFabric platform exhibits. And that this 'namespace' could only be implemented inside the boundaries of a single server, sort of how SharePoint Search was originally single-server, and then later became enabled across multiple servers.

Putting all that together, I was guessing that searching depended on the region-based indexing capability and therefore that 'searchable' keys would necessarily result in the limitation that all data cached in a 'searchable' area would be placed in a region, and that would lead to a 'concentration' of data in a region on a single server.

And my question was intended to elicit confirmation or elucidation of my understanding.

And so far, you have answered many of my questions, but not that one precisely.

Thanks,

Kimball

It appears that 'tags' allow us to associate a 'search term' with the objects placed into the Velocity cache space.

However, these can only be queried within a 'region'.

Further, regions somehow limit the locality of objects in the cache to a single server (or maybe something kinda like that).

So this appears to make it hard to perform any operation for which the unique Id of the cached item is not persisted or continuously available to the application that stores and retrieves objects to and from the cache.

In any case, I can't see an easy way to 'cleanse' the cache of objects or to find objects across the entire cache that may share some prefix, postfix or infix values in the cache key so that i can clear out the cache of object repeatedly created in unit tests, for example.

And I am unsure about the consequences of regions being associated with single server cache locations.

So I would appreciate any help with the following questions:

1. What is the difference between a 'distributed cache' (called a 'partitioned' cache??) when using regions, and a 'local cache'?

1.a. In particular, are the region-oriented values in a distributed cache visible through a cache factory that is configured to 'see' the entire cache space?

1. Are the operations of creating and removing 'regions' efficient enough that it would be reasonable to create a region and a group of tags for each bundle of objects that need to be cached?

2.a. Or does this just push the problem of scoping the 'search for objects' up the chain because the ability of the DataCache object to query down through regions and tags as limited as querying for the cache keys of objects themselves.

Thanks,

Stato

Answer 1

In the Release Candidate (and since the later betas), the requirement to use a region when adding an item with Tags has been lifted (though I have a sneaking suspicion that under the covers there's a call to cache.GetSystemRegionName and a region actually is being used). However, note that I was playing with the Release Candidate at the weekend, and when you try to retrieve an object based on a tag/set of tags, you are required to provide a region name.

Under what circumstance would you have an object in the cache for which you didn't have a unique id persisted somewhere? e.g. a database key, AD guid etc.

In terms of 'cleansing' the cache, if you do use regions, there's the ClearRegion method, or you could just remove the region, which will remove from the cache all the objects inside the region. You could create an extension method that does pattern-matching on the key and combine that with the GetObjectsInRegion and GetSystemRegions methods to find all the objects in a cache with some token in key, but I think this would be horribly inefficient since you'd have to iterate through every item to examine the key.

1a. What is the difference between a 'distributed cache' (called a 'partitioned' cache??) when using regions, and a 'local cache'?

The (optional) local cache in AppFabric is distinct from the 'central' cache in that it lives right inside your application. Whenever you request a cached object from the 'central' cache, the object then becomes cached in the local cache. Subsequent requests for that object will be fulfilled from the local cache. In an architecture where your AppFabric servers are distinct from your application servers, this could save you a network hop.

1b. In particular, are the region-oriented values in a distributed cache visible through a cache factory that is configured to 'see' the entire cache space?

Not quite sure I understand what you're getting at with this question, an AppFabric client that has access to all the servers in the cluster (a routing client in AppFabric terminology) would by definition have access to every region in the cache. Or is your concern the opposite case e.g. what happens if your client only has access to a subset of the servers in a cluster, but requests an object from a region on a server it doesn't have direct access to? In that case the server the client does have access to will retrieve the object from the region on the other server and pass it back to the client.

1c. Are the operations of creating and removing 'regions' efficient enough that it would be reasonable to create a region and a group of tags for each bundle of objects that need to be cached?

Regions are designed for holding a set of objects e.g. Products, Customers, hence the DataCache.GetObjectsInRegion method, but rather than create regions on an ad-hoc basis I think it's better to create them all in one go, say at Application_Start in an ASP.NET application. Tags, however, are pretty efficient to create since they're more or less just strings.