Microsoft Project Code Named "Velocity" – Followup

Yesterday, we announced the first CTP of Microsoft Project Code Named “Velocity”. This post is a follow-up to clear up  a couple of points that we’ve seen in forums.


First, the usage scenarios. Velocity is intended to provide distributed caching (in memory) for all .NET applications – from enterprise scale to web-scale. We believe that there are many applications that need a distributed caching mechanism, and that there is, therefore, a need for distributed caching as a core part of the .NET platform. We expect to have more integrated support for this functionality with other parts of the .NET platform in our upcoming releases.


ASP.NET applications are an important class of applications that we expect will benefit significantly from Velocity. The current CTP of Velocity includes a Velocity SessionState provider that leverages Velocity to maintain session state in a scalable (and in the future, available) fashion. Velocity can also be used to manage application data (ASP.NET Application Cache) for ASP.NET apps; however, the application patterns there need to be more explicit, unlike in the SessionState scenario.


Our support for ASP.NET is part of the integrated .NET platform story. Rest assured that we are not focusing exclusively on ASP.NET applications alone. As an example, we plan to integrate with plain .NET applications (windows service, for example) or  IIS applications that may not involve ASP.NET.


Now onto upcoming functionality. The current CTP features support for scale-out, local caching  and ASP.Net SessionState integration among many others. We have a full bag of work items we’re looking at for our subsequent CTPs and RTM – including support for availability, replicated caches, notifications, better management support etc.


Push-based notifications is a request we’ve heard from many folks. This is certainly an area we’re looking very deeply into. While our current CTP does not have this support, this is very likely to be remedied in our upcoming releases. In the interim, if you’re using Velocity with a local cache, we have some workarounds for this with APIs like GetIfVersionMismatch() to help deal with potentially stale/out-of-date objects in the local cache. (You will need to use a combination of Get() and GetIfVersionMismatch() to get the right behavior)


We will post a  full description of CTP1 functionality later today. In the meantime, stay tuned for upcoming updates.


Let us know what you think. Would you use this functionality, and how/when ? What kinds of data would you like to cache? What features do you think will make this a better story? What pieces of functionality are completely missing?


S Muralidhar



Comments (9)

  1. sdonovan_uk says:

    Firstly, congratulations on the CTP.  We had a chat with some folks in Redmond about this last year and it’s very proactive.  🙂  The API is simple, yet appears powerful and promising.  I can imagine that the clustered approach is somewhat a challenge.

    To add to the previous comments (I’m also in the financial derivatives IT business):

    – When using a grid, caches are useful.  But, a LOT of legacy pricing models are native C++.  You should consider a unmanaged C++ API version of the cache-client.

    – Yes, **please** implement PUSH notifications.  We can envisgage using a cache as a messaging-system in it’s own right, so it’s a hard requirement (unless we getting into tedious polling).  Obviously, need to examine latency, concurrent updates, etc.

        . . . . with PUSH, can we have a Tag-based filter?

    When PUSHing, a cache-entry would probably be (also) tagged with a Sequence #, or a TimeStamp.  That would queried against.

    API specific:

    – CreateRegion(..).  If you create an existing region, it exceptions with the generic CacheException.  Wouldn’t it be better to have an additional call to check to region existance?  Or, is the preferred approach to check the errcode on the Exception?

    – CacheItemVersion; there’s no public/get/property to get the Version #.  That would be useful.

    – Tags (performance); the fact that it has a queryable interface is fantastically useful.  But, what’s practical performance like?  If I have 10,000s to 100,000s (across different regions) of cache entries, each with 20-30 tags, what happens?

    – Tags (vs. Keys).  In our case, the CacheItem’s Key would be built up of subkeys (e.g. HEDGE/HEDGE1/TRADE001).  Effectively each part of the key is really, also, a Tag.  It would seem too confusing to make them interchangeable, but please bear this in mind.

    – Have you thought about security implications?  As it stands, you’re assuming that the cache-servers are all behind a firewall — that’s fair.  But, it could be considered unsafe to allow any access, to any data.

    – Perhaps I missed it, I didn’t see any notes on the cache distribution policy.  Are all cached keys/objects sent to all cache servers?  If so, the cache-process looks Win32, isn’t that restriction?  How will you handle this?  


  2. joewood says:

    Like many other comments:

    Push distribution support.  Something scalable like a PGM (NACK) based solution would be ideal – that downgrades to unicast if the network doesn’t support multicast.

    Full integration with astoria and the Entity framework’s interfaces for CUD (i.e. IUpdatable etc)

    When you have push support make the protocol open so that it can be consumed on the client side for Rich clients based on a server executed live query.

    Use cases – other than traditional web session state:

    Useful for aggregation of real-time data.  Could be market data, monitoring metrics (think aggregated WMI/PerfMon metrics).

    Avoid read/write conflicts in high through-put transactional systems.  Read/write contention can be better managed using a cached version of a data store – as long as provision is made for some propagation delays in the app logic.

    Useful for increasing capacity of transaction systems.  A disperate distributed cache can reduce the risk of failure and the need to persist to storage for each transaction.  This reduces exposure to failure without the need to commit to disk on each transaction.

  3. gOODiDEA.NET says:

    Web Facebook Open Platform 25 Excellent Ajax Techniques and Examples Profiling your AJAX Applications

  4. velocityteam says:

    Thanks for the feedback, Sean. Some responses

    Unmanaged client access to Velocity: Yes, this is definitely something we’re considering

    Notifications: we’re still in the design phase for this. And we know that this is a fairly tricky problem to solve. What we’re trying to build is a set of simple building blocks, that can then be composed in many interesting ways. We’ll have more updates on this soon

    API questions

    Adding an accessor for version: Sounds pretty reasonable. We’ll look at adding this to future versions

    CreateRegion: I tend to favor the current model (gives you an "atomic" create-or-error mechanism); Would having a more specific exception help ?

    Tags performance: Currently tag-search is restricted to a "region" (which must reside in its entirety on a single node). That allows us to bound the processing time for a tag-search. We’re looking at cross-region/cross-node tag searches, but like you say, this gets pretty expensive pretty soon

    Tags vs Keys: I look at tags as alternate keys (partial keys) for a cached item

    Security: We’re looking into how we can have better support

    Distribution policy: In the current CTP, we support only a "partitioned" cache (ie) each node contains only a (disjoint) subset of the overall data. In other words, for each cached object, there is a single node that "owns" the object. We maintain a partition map that allows to identify what objects (more specifically, what keys) live on what nodes, and this controls the distribution policy


    S Muralidhar (MSFT)


  5. velocityteam says:

    Thanks for the feedback, Joe.  

    >> Push distribution support.  Something scalable like a PGM

    We’re still in the design phase for this functionality, and we’ll definitely take this into account.

    >> Full integration with astoria and the Entity framework’s

    >> interfaces for CUD (i.e. IUpdatable etc)

    Can you share some more information on how you’d expect to use these together?

    >> When you have push support make the protocol open so that it >> can be consumed on the client side for Rich clients based on a >> server executed live query.

    Agreed. We’ll keep this in mind as we design this capability.

    Thanks for the suggestions on the other use cases. We’ve been thinking on very similar lines, and all of these are ideal scenarios for a caching solution (especially for applications that can tolerate a bit of staleness)


    S Muralidhar (MSFT)


  6. gby630 says:

    作者JonathanAllen译者胡键发布于2008年6月11日上午5时8分 社区








  7. Is the CTP posted someplace?  where?  How about the current api doc?

  8. HeroBeast says:


Skip to main content