I am working on how to implement caching in the best possible manner when we are implementing

I've visited this one a few times over the past couple of years.

Firstly, whatever architecture you choose, the cache should carry an invalidate method for the data you choose, and it should automatically repopulate. That way, whenever you save data thats stored in the cache, you invalidate it, and the next time a process tries to access the cache - it will automatically repopulate.

We have used memory mapped files in the past but we were concerned with a theoretical build up of MMFs as there is no way to delete them except reboot (no way to delete them if the process gets canned as in an iisreset)

So then we moved the cache to an xml file which is loaded into memory as the cache loads. You can make the cache a serializable class. When the data gets invalidated, the xml file gets deleted and then the cache will rebuild it automatically.

To make a cache available to all processes you either need MMF, write it in the registry (please dont), use .NET singleton remoting, or write it to a text or xml file and rely on the operating system to cache the file, which seems to be a reasonable assumption these days. We are writing the cache to an xml file, which then gets loaded on first cache use, and if it doesnt exist the cache recreates it.

Hi Paul,

Thanks for your elaborate reply.

I am actually doing a study on different caching pattern which can be adopted in different locking scenarios like in optimistic locking ,pessimistic.

Let me make it more clear.

I wish to know that if an application is using optimistic concurrency as the base, how should i implement the cache ,if we can't tolerate stale data at all and if we can tolerate stale data but only for some seconds.

In this case i need to know all the aspects of putting the cache in place like

1. At what moment of time should we invalidate the cache like at the start of transaction , just before updating the database or any other time

2 When should we lock the cache

3. how should we overcome the data retrieval latency issue which ultimately lead to stale data for some time in cache 

4. if a thread is making some changes in a data in database how can we make sure that cache gets refreshed for the other thread to get fresh value. 

5. Should we update the cache inside the transaction or after completion of transaction (in both scenarios of wanting and not wanting stale data) 

6.If one thread is reading or writing a value to cache, how to block other threads to access that cache object. 

Similarly for pessimistic concurrency

Hope i am able to clarify my query

It would indeed take some of your time but i would really appreciate if you can give your inputs on the above

regards 

Sorry short of time so just a quick answer...

1. At what moment of time should we invalidate the cache like at the start of transaction , just before updating the database or any other time
Just before you commit, lock the cache with a mutex, and make every other process sleep until the mutex is freed

2 When should we lock the cache
As above. No need to lock the cache when reading

3. how should we overcome the data retrieval latency issue which ultimately lead to stale data for some time in cache
A cache should never be out of date if it contains critical data. Lazy processes to update caches are invariably more complicated so just update the cache the first time data is needed after an invalidate

4. if a thread is making some changes in a data in database how can we make sure that cache gets refreshed for the other thread to get fresh value .
All your database updates should go through a central sql processor, so you know that everything thats written is seen by the business class software. If you're allowing cache on an application that allows direct sql updates, you'd have to write triggers to flag the cache as invalid - then the cache has to inspect a database value to see if its invalid which is slow and therefore defeating the object of a cache. In our case its all business class based with no option to exec sql directly

5. Should we update the cache inside the transaction or after completion of transaction (in both scenarios of wanting and not wanting stale data)
Cache should be invalidated inside the transaction. There is no need to repopulate the cache at that point in time. Just repopulate it next time a thread comes in that wants cache data.

Hi Paul,

Thanks for your elaborate reply

Regards

Leo