Part 3 in this series:

Check out the Velocity CTP, which provides a distributed memory-based cache. The canonical example of its use seems to be scalable storage of session state in an ASP.NET application, such as for shopping cart data.

This distributed caching implementation raises some interesting questions about security model, by the way. Per this blog post from the Velocity team, a typical configuration is for the cache to be exposed as a system service listening on a high port (22234 in that example).

In a typical deployment, I wouldn’t be surprised for data to be read from a persistent store, such as a SQL back-end, and then end up in the session state (and hence in the distributed cache). Is that data sensitive? Does the user’s credit card number end up in the session state? It’s one thing to protect the data in SQL; there are robust principal-based access control solutions for that that most administrators and developers are at least aware of.

But applying equivalent access control to a port is tough. I guess the best solution will be firewall rules that specify which sender IPs are allowed. That’s harder to administer, though, and it’s never handled by the application installation and configuration programs.

By the way, if you need a production distributed caching solution, I recommend checking out Seattle-based ScaleOut Software, which has had something similar on the market for several years.

No Comments »