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

Architect

Comments

• Anonymous
  June 03, 2008
  PingBack from http://mdavey.wordpress.com/2008/06/03/thoughts-for-the-velocity-team/

• Anonymous
  June 03, 2008
  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?   Sean

• Anonymous
  June 03, 2008
  The comment has been removed

• Anonymous
  June 03, 2008
  Web Facebook Open Platform 25 Excellent Ajax Techniques and Examples Profiling your AJAX Applications

• Anonymous
  June 05, 2008
  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 Thanks S Muralidhar (MSFT) Architect

• Anonymous
  June 05, 2008
  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) Thanks S Muralidhar (MSFT) Architect

• Anonymous
  June 15, 2008
  作者JonathanAllen译者胡键发布于2008年6月11日上午5时8分 社区 Architecture, .NET, SOA 主题 .NET框架, 企业架构 标...

• Anonymous
  June 16, 2008
  Is the CTP posted someplace?  where?  How about the current api doc?

• Anonymous
  November 28, 2008
  在过去几年里，从主流的Java应用到象Erlang这样的边缘语言，分布式内存缓存的应用相当流行。为了继续疯狂赶超开源世界中处于支配地位的技术，微软也引入了它的分布式缓存。Velocity是专门针...