Project "Velocity" CTP1 Features

Hi,

 

I hope you got a chance to visit our velocity page, download the bits and try it out – We are waiting to hear your feedback and you give it us by commenting on this blog page or by visiting us on our velocity forum.

 

I want to talk about our CTP1 features in this post.

 

Our CTP1 features spanned the following areas – I have one line descriptions for these to keep this entry short, if you need to learn more about these areas please read our whitepaper or our documentation that comes with the velocity install

 

1. Support for different cache types

a. Partitioned Cache

This allows the data to be partitioned among all of the available nodes on which the named cache is defined.

b. Local Cache

This allows for very frequently accessed items to be kept in the object form within the application process space.

 

2. Support for different client types

a. Simple client

Simple client does not know about any routing and always contacts one node which will forward the request as needed

b. Routing Client

Routing Client knows the routing table so it can contact the node that has the object directly thus saving a network hop.

3. Deployment topology

a. Cache Service

In CTP1, you can configure a cluster of servers to host your cache and provide a cache Service. Any number of clients can access this cache service.

4. Concurrency Models

All cache operations are atomic and we provide the 2 models below when working with updates.

a. Optimistic concurrency model

“Velocity” supports version based updates and with this model when you retrieve an object you also get its version. When you add the updated object back to the cache, you pass in the version and if it is the same as the version you retrieved, your update succeeds.

b. Pessimistic locking

“Velocity” also supports for explicitly locking an object to perform updates

5. Expiration by TTL & Eviction using LRU

“Velocity” allows you to deal with stale objects by setting expiration policies using TTL and maintain available memory capacity through eviction.

6. Load Balancing & Dynamic Scaling

With “Velocity”, you can add new nodes to your cluster if you need to either increase the data that you want to cache or increase the throughput or decrease the response time. “Velocity” will do implicit load balancing and new data will be cached in the new machines and existing partitions may also be migrated to the new machines to load balance.

7. ASP.Net Integration

“Velocity” provides a session store provider that allows you to store your ASP.Net Session object in “Velocity” cache – This enables non-sticky routing allowing scaling your application.

8. Key based Access

“Velocity” supports simple key-based access. The cache access methods take in a key that uniquely identifies the object.

9. Tag Based Access

You can also associate tags with each object to describe it and you can retrieve objects based on tag values.

 

 

 

What’s beyond CTP1 –

1. Availability – support for Failover when machines go down

2. Replicated Cache – another cache type

3. Embedded Topology – run the cache embedded within you application instead of as a cache service

4. Notifications – Get notified when a object in the cache is updated

5. Consistency Models – Support for both weak and strong consistency when doing reads/writes

6. Native client access to the cache service (E.g – PHP, C++ etc)

7. Manageability & Administration

 

We are working on our next CTP plans and if there is a feature that is really important to you in the list above or if there are features that you expect to see but is missing from this list, let us know –

 

Thanks

Nithya Sampathkumar

Program Manager