Don't play with items stored in InMemory cache

How often do you use a form of in-memory store in your application? My guess is "a lot". There are multiple variations of the in-memory store that you can use - MemoryCache, Custom Dictionary, Http Cache, Application Cache etc. They all use process memory as the store for keeping the information (read objects). One great thing about in-memory cache is that it is FAST :). There are downsides though.

1. It adds to the total memory hogged by the process over its lifetime. Unless you have a good eviction strategy in place, the objects will just remain there forever. That may or may not be an issue depending on the context of the application.

2. General implementation of such cache is to keep objects as-is in its store. e.g.

Cache.Add("Key", obj);

Above code means that whosoever holds a reference to the object can still make a change to the object - what does that mean?

Say, 

1. Class 1 and Class 2 have reference to one object Obj1. 
2. Class 1 saved the object to cache. 
3. Class 2 made a change to the object in its implementation. 
4. Class 1 retrieves object from cache.

Class 1 will get the updated values and that can surprise the program logic :)

So what should we do?

Couple of options:

1. Serialize the object before storing in cache. e.g.

Cache.Add("Key", Serialize(obj));

2. Clone the object before storing in cache.

Hope this helps in catching strange issues if you use in-memory cache.

PS: Distributed cache stores do not have this issue as the objects are serialized before being transferred over to the cache store.