ASP.NET Cache Store

Topics: Caching Application Block
Feb 2, 2007 at 8:29 AM
Is there any reason against an ASP.NET backing store? It seems like an obvious add so you can use the same cache technology through all layers of your application.
Feb 2, 2007 at 2:52 PM
I personally love the idea, but the Caching Application Block is meant to be used for persistent storage. If you want in-memory caching, the documentation recommends you use ASP.NET Caching because it is much more feature rich. You can find various tutorials on the Internet that dicuss creating a wrapper around the ASP.NET Cache and Session State to abstract it a bit from your application.

On another note, if you are talking about a web application, I recommend looking at the new Web Client Software Factory. It uses the new Composite Web Application Block which does a lot of plumbing and uses Enterprise Library 2.x under the covers.




David Hayden
Microsoft MVP C#
Feb 2, 2007 at 6:19 PM
The ASP.NET cache essentially provides the same feature set as the Caching Application Block, with the notable exception of support for backing stores. While you don't need to use backing stores with the block, there's not a lot of reasons to choose the block if you don't need this feature. While it would probably be possible to build a caching block backing store that called the ASP.NET, I'm not sure if there are any benefits of mixing the two technologies.

BTW when we first built the caching block, the ASP.NET cache was not supported for non-ASP.NET applications, so this was a major reason we built the block. However from .NET 2.0, the ASP.NET cache is supported for other app types (despite the fact it still lives in the System.Web namespace). So the block is still here mainly for the backing store support, but it's unlikely we'll invest a lot in it in the future.

Feb 2, 2007 at 6:25 PM
Thanks for the insight David and Tom!
Feb 4, 2007 at 6:09 AM

tomhollander wrote:
So the block is still here mainly for the backing store support, but it's unlikely we'll invest a lot in it in the future.

Does that mean the Caching Application Block is likely to become stale? Admittedly, the ASP.NET cache is fantastic, but since we're talking Enterprise Library here there could be room for many additions to the Caching Application Block. A few come to mind immediately:

- Clustering with support for various cluster node configurations like master-slave, master-slave groups and hybrids thereof

- New expiration policies such as idle time expiration

- New eviction policies (current strategies are scarce) with clear cut definitions such as priority based eviction, LRU, LFU

- Adding read-through, write-through caching

Apart from that there are many ways to improve the block even if you do not require these advanced features. Hashtables are neat as a storage data structure but there are more effective data structures out there such as B-Trees. More compact serialialization for persistent cache stores or passing cache items over the network would also greatly benefit overall performance.

'Tis a shame if active development would stop on the Caching Application Block as there's so much potential in it and let's face it, all our nice IoC, ORM and lord knows what else applications will always need the best caching possible ;-)

I hope the Caching Application Block will never expire.

Feb 9, 2007 at 3:12 PM
In the scavenging process, if the cached items all have the same priority, what algorithm the ASP.NET caching API and Enterprise Caching Application Block will used to decide which items should be removed first to release some memory space?

I am investigating which caching API is better for our application. It's difficult to use a priority based scavenging policy, we prefer the LRU or LFU algorithm. I have search online to try to find out what algorithm is used if caching items have the same priority, but no luck so far. Hope someone can give me ideas here.

In one online ariticle about Enterprise Caching block, it said:
The onus of the items that need to be scavenged is placed on the BackGroundScheduler object. The BackGroundScheduler performs a:

* major sort on priority
* minor sort on LTA

Does anybody know what LTA is?

Some articles suggest that we should use ASP.NET caching unless we are not using in-memory storage. If we have to implement our own scavenging policy, I think we can only use the Enterpise Caching block because at least we can change the source code. Any suggestions?

Thanks in advanced
Feb 9, 2007 at 3:53 PM
I just download the Enterprise Library Caching block and have a look the source code in PrioritydateComparer.cs, seems if priority is the same, then will compare by the last acess time, so it's based on LRU. Please correct me if I am wrong.

Still can't find out what algorithm ASP.NET caching use for the same priority items.
Mar 20, 2007 at 10:53 AM
Can I just add support for maintaining the caching application block.

The built in cache is not configurable (as to where the data is stored) and does not fit our needs. The caching application block is a brilliant piece of work and a great abstraction to work against. We need to have the cache independent of the backing store because we are sharing our business logic and data access logic across many different services including web apps, services and winform applications, the ASP.Net cache does not suffice.

The ASP.Net cache is not transient across server restarts.
The ASP.Net cache is not shareable across threads or machines.
The ASP.Net cache cannot persist to any other store.
The ASP.Net cache is therefore not scaleable.

Please please, keep and enhance the Cache Application Block.
Please add an ASP.Net cache BackingStore class so that everyones apps can be completly independent of the cache.

Kind Regards,
Paul Kinlan