o cache objects returned from a service, you can use one of several available mechanisms, the simplest of which is to reference the objects indefinitely. However, this approach ultimately suffers if an application caches too much data. Alternatively, you could use the Microsoft Caching Application Block
(CAB), an extensible module that facilitates common caching scenarios. But when you're creating a sophisticated architecture requiring that no more than one copy of a given object (such as a customer record) exist in memory at a given time, the CAB won't suffice.
One such scenario arises when you're implementing change notification. To implement change notification in a service-oriented environment, the client needs to have a reference to all client objects to deliver events. When using traditional caching techniques, such as the CAB, there is a delay between the time that the cache releases the reference to an object and the time that object actually gets collected, because the UI is still referencing the formerly cached object. During this time, there is no way for a change notification event to be routed to the object. Also, while the UI is still referencing an object (but the cache is not), the client framework will create another copy of that object the next time the UI asks for it (perhaps in a different screen).
Fortunately, you can approach the problem another way—by using the WeakReference
class. According to the MS documentation, "
the WeakReference class cannot be treated as an automatic solution to memory management problems. You still have to establish rules for your application, that is, a caching policy, about what entries are kept or removed from a cache." However, building a cache manager that uses WeakReference objects is a viable approach.
The solution described in this article uses a combination of a WeakReference and a strong reference to create a cache that will meet the application's demands.
This solution revolves around the CacheReference<T> class. At the heart of this class are two fields:
where T : class
private WeakReference m_weakReference;
private T m_strongReference;
Initially, the object you want to cache will be referenced by m_strongReference
. This member is strongly typed (using the generic
), so it performs better than wrapping an object type. You use the m_weakReference
member to mark the object as ready for collection. The Target
property wraps access to these fields. It takes care of returning the cached value or returns null if the object has been garbage collected:
public T Target
//Check to see if we have a strong reference
if (m_strongReference != null)
if (m_weakReference == null)
throw new InvalidOperationException("Unable to return
Target when it has been collected");
//The target has been collected - ditch the weak reference
m_weakReference = null;
m_weakReference = null;
m_strongReference = value;
You need to provide a way to specify that the cached object is eligible for garbage collection. To make the cached object collectable, switch from using the strong reference to the weak reference. That change allows the garbage collector to collect the object (if there are no other references to the object). One additional benefit of the CacheReference class is that an object that has been marked as collectible can be promoted back to a strong reference if it has not yet been garbage collected. This behavior is governed by the AllowCollection
property (see Listing 1