CallContext
Many a times, it would be necessary to share some common information/data between methods that form a call chain. For example, consider a call chain like the one shown below:
A(); --> B() --> C() --> D();
And lets say B,C and D need to access some information created in A. Lets look at some common ways of doing it
1. Create placeholder parameters in all methods.
This is the least elegant solution in most situations, especially in cases where that data is optional. Creating overloads might clutter up the class definition.
2. Using static members/properties
class DataStore
{
private static Hashtable _slots = Hashtable.Synchronized(new Hashtable());
public static Hashtable Slots
{
get { return _slots; }
}
}
Static instances live until the AppDomain unloads and can be used to house data, and they would be used through the Singleton pattern. This may be a better solution than creating as many parameters in each method in the call stack. But, you would need to be careful with its design and usage as you may need to synchronize access to a static member in a multi-threaded environment. It would be nice to have a framework expose a common data store which could be accessed across methods. CallContext is just that. The CallContext class provides data slots that are unique to each thread of execution. You can use the SetData and GetData methods to create and retrieve values from named place holders. The usage seems very similar to that of named/unnamed data slots of the Thread class. So, you may ask - When do I use which method? The answer really lies in the namespace CallContext lies in : System.Runtime.Remoting.Messaging and this is where the similarity ends. Using CallContext, data can be passed along with method calls that are remoted (which execute in different a AppDomain). However, to make this work, the classes of those objects have to implement ILogicalThreadAffinative interface. This interface is just a marker and does not contain any methods to be implemented. And of course, the objects should be serializable.
One good use of CallContext could be a case where a caller's Identity information could be stored in the call context. The remote method call could access this information to implement some sort of a Role-based Security.
You can also have a look at this well-written entry on CallContext. For more information and samples, refer to MSDN.